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

From: Lennart Poettering <mzynq@email-addr-hidden>
Date: Mon Jun 22 2009 - 18:26:25 EEST

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-dev
Received 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