On Thu, Dec 05, 2002 at 02:34:15AM -0500, Greg A. Woods wrote:

> That's _really_ _NOT_ a problem if the various parts of the system work
> together properly.  If we don't already have a decent timesharing
> scheduler then we need one regardless (but I think we already do have a
> half decent scheduler -- I get decent interactive response on recent
> kernels even with the load average over 12 and with only a pair of
> mid-speed IDE drives on the same controller, both getting hammered by
> file I/Os and paging activity)

I agree that once the process limits are reached (which would happen
quite soon in the case of a fork(2) bomb) it seems a better idea
to either cause the scheduler to properly renice the processes which
don't behave properly so that the system remains responsive, and/or
to trust the administrator to set a suitable maximum number of
seconds and let the kernel kill that application itself...

It's a general problem otherwise, because one could fork(2)
as much as the process can and then run any loop using another
set of expensive syscalls. If special fork(2) delays were
implemented it would in fact serve no real purpose but to
faint the first attack, if any

Matt