On Sun, 21.06.09 21:02, Paul Davis ([email protected]) wrote: > > On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering<[email protected]> wrote: > > > > 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?
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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
