This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Slow pthread_create() under high load
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Subject: Re: Slow pthread_create() under high load
- From: "Stephen C. Tweedie" <sct at redhat dot com>
- Date: Mon, 27 Mar 2000 16:58:01 +0100
- Cc: "Stephen C. Tweedie" <sct at redhat dot com>, sasha at mysql dot com, Alan Cox <alan at lxorguk dot ukuu dot org dot uk>, drepper at cygnus dot com, glibc-linux at ricardo dot ecn dot wfu dot edu, linux-kernel at vger dot rutgers dot edu, mysql at lists dot mysql dot com, monty at mysql dot com
- References: <20000327122416.A4161@redhat.com> <Pine.LNX.4.10.10003270747480.20939-100000@ashi.FootPrints.net>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
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