22 Jun
2009
22 Jun
'09
1:26 p.m.
On Sun, 21.06.09 21:02, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
What SCHED_RESET_ON_FORK fixes is that a process cannot fork() (as in
process) to evade the kill() of a supervisor process.
Without this flag you always have a race where the killer process
would have a hard time killing a process that is duplicating itself
exponentially.
What matter is that to put an end to the thread bomb process all we
need to do is one call to kill().
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
The distinction between a thread/clone() and a process/fork() bomb
doesn't really matter. What matters is that you can kill() processes
and make the whole issue go away in one step even if that process has
one gazillion threads and wants to create even more.
that was sort of my precisely my point. i only read your patch, i
didn't look at it in the context of the whole kernel. if indeed it
only applies to fork() and not to clone() calls that create threads
and not tasks, then its not really protecting against anything, is it?
however, from what i could see of the patch the no-inherit-RT property
belongs to the process, not a thread, and thus could not be reset by a
thread create call without wierd semantics.
so it appears to me that your patch still leaves the kernel open to a
thread-bomb ... am i wrong?