[ On Wednesday, December 4, 2002 at 19:18:31 (-0800), Phil Nelson wrote: ]
> Subject: Re: Fork bomb protection patch
>
>  On Wednesday, December 4, 2002 at 10:07:35 (+0100), Jaromir Dolecek wrote:
> 
> > Subject: Fork bomb protection patch
> >
> > * make process sleep for 0.5s if the system table is full
> >   or when the user reaches their process number limit
> >   - this is to not hog the system with huge number of CPU-hungry
> >     looping processes
> 
> How about having this .5s sleep kick in only after a user has had 
> a number of unsuccessful forks without a successful one.  This would still
> stop the fork bomb, but let non-bombs that run at the process limit continue
> without the .5s sleep.

Non of these "forced sleep" ideas will do anything to stop the fork bomb
per se -- all they will do is reduce the amount of CPU such processes
might consume and maybe, just maybe, allow a few of their already very
few active pages to be paged out for a tiny amount of time.  But that
doesn't really help in any significant way (other than save some
operator who was trained in single-user system environment a few hairs
while he or she frets about all the wrong things).

Such bad hacks are not necessary -- and they don't really solve anything.

All they do is add unnecessary complexity that can only get in the way.

Even if these processes are spinning in an idle CPU loop they cannot
stop a proper timesharing system from allowing other authorised users
from getting some work done.

What if one of those spinning processes is actually being run by the
administrator in an attempt to find out what all the others are doing?

There is no possible generic way such a scheme can relibably
discriminate between the good process(es) and the bad one(s) -- and no
need or reason for it to do so either.

The best possible thing for the system to do is to simply cause the
fork() call to return an error with EAGAIN and to continue to do the
normal thing to ensure CPU hogs are only given their fair share of
available cycles.

The last time I had to reset a *BSD system that was out of processes it
was because the consumer was running as root and nothing could be done.
Too damn much stuff runs as root.  The best fix is to stop running
nearly everything as root, not to try to endow the kernel with psychic
abilities such that it can out-guess even the administrator.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>