On Sun, 21.06.09 21:02, Paul Davis (paul@email-addr-hidden) wrote:
>
> On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering<mzynq@email-addr-hidden> 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 Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/mailman/listinfo/linux-audio-devReceived on Mon Jun 22 20:15:05 2009
This archive was generated by hypermail 2.1.8 : Mon Jun 22 2009 - 20:15:05 EEST