On Thu, Dec 05, 2002 at 01:33:36AM -0500, Greg A. Woods wrote:

> 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.

The fork(2) specific tsleep(9) indeed seems a bad hack to me, but a
more general solution to allow a system to always generally remain
more responsive doesn't

> 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?

The administrator (superuser) can renice his processes as wanted;
There also is an obvious difference between a process group with
10+ processes using all CPU they can and a process like top
IMHO.

> 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 scheduler needs to do this already, it just could do it slightly
better

> 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.

Yes to the userspace it should appear as such, I fully agree.
I previously started a thread on this mailing list about similar
operations for memory allocation but it seemed a problematic
approach with current uvm state; I personally advocate return
code checking in all situations myself

> 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.

I was quite surprised when running alot of bombing tests (also tested
bombing TCP stack, mmap(), sysvipc, and various ressources, when
trying NetBSD at first... I indeed was surprised at how well the system
could recoop from most heavy attacks compared to Linux 2 kernels I was
used to at the time. I however feel that it still could be slightly
better IMHO...

Matt