Bill Studenmund wrote:
> That is true, however when did Roland's objection come by? I've lost track
> of the exact dates.

Yes, that objection was before the commit.
 
> 1) This is a natural consequence of being a time-share system. As Greg
> pointed out, it's been known for a LONG time. The fact that it hasn't been
> "fixed" is telling - all the "fixes" folks have come up with aren't.

It isn't entirely trivial to solve this in really proper way IMHO.
It's my understanding the time-sharing scheduler doesn't cope with
the fork-bomb too well, since there is huge number of CPU hungry
processes. As a result, each gets only fraction of CPU, collects
CPU ticks very slowly and thus it's priority won't get lowered
quickly enough. Thus, it's priority pretty much stays at PUSER and
effectiverly block process activity on this priority.

My guess that since fork-bombs normally don't happen, it simply
wasn't important enough to adjust scheduler to handle stuff like
this.

> 2) Roland pointed out his system didn't die when the bomb was going off,
> so the, "we prevent a death," claims don't seem to hold water.

There were never "we prevent a death" claims, not by me at least.
 
> 3) What about Roland's modified bomb? I haven't tried it, but I trust him
> when he says that, even when he added a 1 second wait after fork failures
> (to simulate your .5 sec wait), it behaved the same. Thus the delay
> doesn't stop that bomb; the scope of this fix is limited and easily
> circumvented.

Andrew already answered this one. Roland's modified bomb used
for(;;) after fork() failure, not a sleep(1).

The change never intended to be ultimate protection against
fork-bombs. It's merely a clever hack to catch the most frequent
programming mistakes and system probes, and keep the system
responsive in those cases, so admins would have easier job.

> > The sleep thing is smart & simple solution to tough problem. I don't
> > see how it could cause any new problem. So I currently don't see why
> > to not have it there.
> 
> 4) What happens to "non-rogue" programs that run into this limit? They get
> a random 0.5 second delay. That will lead to strange behavior & random
> "freezes". ??

Arguably, the sleep doesn't make any difference to behaviour
perceived by most programs.  Most programs just busy loop trying
fork() for EAGAIN case, thus effectively 'freeze' when they hit
limit too.  Other programs exit with error if fork() fails. The
latter programs would just take a bit longer to return the error,
which would normally be perceived as system overload (which would
be right). All in all, it pretty much behaves as before, just spends
less system resources on it.

Jaromir 
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-