[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Lennart Poettering mzynq at 0pointer.de
Mon Jun 22 15:26:25 UTC 2009


On Sun, 21.06.09 21:02, Paul Davis (paul at linuxaudiosystems.com) wrote:

> 
> On Sun, Jun 21, 2009 at 8:05 PM, Lennart Poettering<mzynq at 0pointer.de> 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



More information about the Linux-audio-dev mailing list