erh@nimenees.com wrote:

> On Tue, May 30, 2000 at 09:45:53PM +1000, Simon Burge wrote:
> > Folks,
> > 
> > In relation to a ipcs-type sysctl(), given the choice between doing (for
> > example) 128x 60byte copyouts or one 8kish malloc and a copyout(), which
> > would be the better choice?  I'd guess that the latter would be quicker,
> > but could it be used as a serious DOS-type attack on kernel memory if
> > lots of processes were to call the sysctl() at the same time?
>
> 	Unless you used a semaphore to have the sysctl keep track of
> and limit the number of concurrent calls.  Or even limit it to one process
> at a time.  How many different processes at once are going to want this
> information?

The sysctl will appear atomic to the process, so there's no need to
limit the call on a per-process basis.  In theory, there shouldn't be
many processes using this sysctl - how many people sit there running
ipcs(1) all day for something to do? :)  It's the bad guys I was
worrying about - starting something like a fork/ipcs bomb...

Given Bill's reply, this time around I wont worry about it.  However,
would a simplelock be the way to go to control access?  Something like:

	sysctl_sysvipc(..)
	{
		...
		simple_lock(&sysctl_sysvipc_slock);
		malloc(...);
		...
		free(...);
		simple_unlock(&sysctl_sysvipc_slock);
		...
	}

It looks like the only problem with this is that there's no sysctlinit()
to call "simple_lock_init(&sysctl_sysvipc_slock);"...

Simon.