Subject: Re: Fork bomb protection patch (Was: Re: CVS commit: syssrc/sys/kern)
To: Greg A. Woods <firstname.lastname@example.org>
From: Olaf Seibert <email@example.com>
Date: 12/10/2002 02:45:09
On Sun 08 Dec 2002 at 20:29:16 -0500, Greg A. Woods wrote:
> [ On Sunday, December 8, 2002 at 12:09:05 (+0100), Jaromir Dolecek wrote: ]
> > Subject: Re: CVS commit: syssrc/sys/kern
> > It's perfecetly legit for fork() to block until the child can be
> > forked. The EAGAIN thing is optional. SUSv3 says:
> I don't believe that's a valid interpretation of the standard, nor of
> the way it should be implemented in a unix-like system.
Any system call can take an arbitrary amount of time. I don't think
there are many systems call for which anything else is guaranteed. From
that point of view, the correctness of any 0,5 second delay cannot be
The simplest reason for such an arbitrary delay is simply scheduling: on
exit from kernel space, a process may be pre-empted by higher-priority
processes. This may take an arbitrary time, because I don't think there
is any guarantee about the scheduling algorithm to be used (after all
we're not VMS).
Any other artificially introduced delay is simply indistinguishable from
Not that I want to argue is is a good idea, but just quoting from
standards is not going to be sufficient proof for the opposite.
___ Olaf 'Rhialto' Seibert - rhialto@ -- Woe betide the one who feels
\X/ polderland.nl -- remorse without sin - Tom Poes, "Het boze oog", 4444.