Re: Slow pthread_create() under high load

["Stephen C. Tweedie" <sct at redhat dot com>]

Hi,

On Mon, Mar 27, 2000 at 07:51:45AM -0800, Kaz Kylheku wrote:
> > 
> > This is part of a kernel defence mechanism, and yes, it is important to
> > do something like this.  If you don't, then a user can create a fork-
> > bomb task which continually forks off children, and if the children and
> > parent all keep the same credits, then it becomes essentially 
> > impossible for any other process ever to get scheduled.  It is a _nasty_
> > denial-of-service attack, and that's why the kernel has to share the
> > scheduling credits out when you fork.
> 
> So what you are saying is that we effectively have that behavior which is
> called ``process scope scheduling'' for threads.

Not at all --- separate threads are scheduled entirely independently.
It is only on thread creation that the initial scheduling credits held 
by the parent get split across the two tasks.

The reason for the split is that if you did not do this, then fork()ing
would result in two processes each with as many credits as the parent
had before.  In a fork bomb attack, one of these processes will run 
until it schedules, but you are then left with a child process that 
still has full credits, and _it_ can then continue the fork-bomb attack.
For as long as the attack runs, there is always a new child process which
has as many scheduling credits as the original forking task had, and this
makes it very hard to get _anything_ else done in the system to combat
the fork bomb.  For example, the resulting process tree is essentially
unkillable, as it can manage to stay ahead in the scheduler queue of
anything root is trying to do to repair the damage.

--Stephen