[ On Monday, December 9, 2002 at 01:22:44 (-0700), M. Warner Losh wrote: ]
> Subject: Re: Scheduler hints
>
> Having done a lot of testing before that patch was committed on my
> bouncer box, I saw that the fork bomb went from a terminal event for a
> system due to local security policies to an easily correctable event.

You have the wrong perception of the problem (or at least it is far too
narrow) and you have applied the wrong fix.  Despite the fact that you
have some evidence for situations where this hack does what you want,
it's still not the right fix for the whole problem class.

There are better fixes which work for the whole range of related problems.

You should start by implementing decent RLIMIT settings.  Proper use of
RLIMIT alone will make the problem managable for all the cases that
proponents of this hack agree are what it was intended for:  accidental
fork bombs.  Been there, done that, and about twenty years ago it even
stopped me from hogging the system I was playing on as a student at the
time (at least once the original SIGXCPU bug was fixed :-).

You should also investigate some of the many fair share scheduler
algorithms that have been widely discussed and even implemented in other
systems.  Done right they could even make it possible for a user to
clean up his or her own mess, and indeed might even allow for logical
ways to control fork-bombs running as root (though I don't know for sure
if anyone's ever really examined that question in detail).

(Yes, a new scheduler algorithm, especially one as complex as a fair
share scheduler, is not as quick a fix, but then again any fix that goes
into the base system sources should not be just a quick and dirty hack!)

> 	2) Rampant forkers.  This will hurt them.  These beasts should
> 	   really have some better limiter in them than hitting the
> 	   wall.  Normal programs don't fork like a sob, so at worse
> 	   they have to wait 1/2s to find out the limits.

You cannot, and MUST NOT, decide arbitrarily within the kernel, and with
no external policy mechanisms, that a process, or group of processes, is
bad and must be penalized like this.  That is VERY wrong, and
demonstrably so.

Those who want the quick and dirty hack now know where to find it.

Indeed if it had not been included as a mandatory feature but instead
had been an option which defaulted to off then I'll bet people wouldn't
even have been so adamant that it be removed from the tree.  I know I
would not have been (though I may still have argued that it's a waste of
good space and a very bad example for people hoping to learn from
reading the code, though I suppose if properly commented even bad
examples can be better than none).

> 	3) But with the one slot, a sysadmin could regain the system.
>            True, in theory, but in practice one slot is too few in a
>            highly networked system.

I don't think anyone is arguing against having more than one reserved
process slot for the superuser.  I'd personally be happy with three or
four, but with the price of memory these days, even on my older sparcs,
ten just fine with me.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>