Priority Increasing

[Roland Dowdeswell]

On 1109583001 seconds since the Beginning of the UNIX epoch
Mike Silbersack wrote:
>

>If you're sure that the program is a forkbomb, why not modify the forkbomb 
>protection that is already present in kern_fork.c:
>
>tsleep(&forksleep, PUSER, "fork", hz / 2);
>
>What it does at present is whenever you try to fork and you've hit your 
>process limit (see limits(1)), it puts your process to sleep for .5 
>seconds.  If you have a better way to tell if something is a forkbomb, why 
>not just do the same thing, perhaps with a shorter sleep.
>
>Don't try too hard to defeat forkbombs, though.  Whenever it's been 
>discussed, someone has invariably pointed out that you could just fork 750 
>processes, and then have those 750 do something else which is kernel 
>intensive, like reading/writing 1 byte at a time.

Also be careful of unintended consequences.  When it was suggested
that we import this tsleep fork-bomb protection into NetBSD, I
mentioned that it would cause pathological behaviour in certain
well behaved applications.  E.g. thttpd.  Thttpd is an event driven
web server which performs quite well.  It does need to fork to
process CGI scripts, though.  If it hits the process limit and is
put to sleep then it will stop serving static web pages---certainly
not the desired behaviour.  I.e. a perfectly reasonably running
web server will quickly fall to its knees if a few too many CGIs
were requested.  There is no way to solve the problem, too, because
thttpd cannot know reliably whether it can fork before it tries
to.

I think that we ended up putting in this ``fork-bomb protection''
conditionally with the default of off.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/