linuxaudio.org

On Tue, Jun 23, 2009 at 4:15 PM, Fernando

Lopez-Lezcano wrote:

quoted text
> On Tue, 2009-06-23 at 15:27 -0400, Paul Davis wrote:

>> On Tue, Jun 23, 2009 at 2:50 PM, Fernando

>> Lopez-Lezcano wrote:

>> >

>> > This is what Lennart wrote in his original announcement:

>> >

>> >> Why not use cgroups for this? Because it's simply a horrible API, and

>> >> using this for media applications has non-obvious consequences on

>> >> using cgroups for their originally intended purpose -- which are

>> >> containers.

>>

>> The problem with this is that the mechanism described there is

>> actually not dependent on the use of cgroups at all. It will limit all

>> !SCHED_OTHER threads whether they are in a cgroup or not.

>

> Not my reading of it. The default 100%/95% split will be allocated to

> root only (the only entity - this is not a group or a cgroup - that is

> there by default). My understanding is that non-root users will not be

> able to run realtime unless that is changed from the default (even if

> other mechanism allows them to run rt). I don't know how you enable the

> whole thing in the first place.

you are right. my initial reading was that "root group" in this

context had little to do with "root" in the traditional sense of uid=0

and more to do with "root of the filesystem" i.e. the root group is

the parent of all other cgroups. but it goes on to say "Therefore you

will not be able to run realtime tasks as any user other than root

until you have done that, even if the user has the rights to run

processes with realtime priority!"
i am also a little confused by what the default values mean (run time = 0)
> The document provides two ways of reallocating realtime real state

quoted text
> (configurable at build time), one by uid and the other by using

> cgroup's. So, yes, you apparently depend on cgroups to get the

> functionality.

true, but what i actually meant was that the measurement and limit

system is in place with or without cgroups.
the API looks entirely usable to me, in the sense that i could easily

imagine a GUI control panel for this that would be comprehensible to

most users.
> Hmmm, did Lennart specifically answer the issue of the clone bomb? I

quoted text
> can't remember and the thread is looong (I had a couple of points that I

> made that seemed to be valid and never got a confirmation reply)...

i   believe he claimed the watchdog deals with this. it was pointed

out that all you need to do is to know the rule the watchdog uses and

you can still pretty effectively lock the machine from the perspective

of a non-CS-y user.
here's my halfway (?) summary:
   "distros refuse to even provide a way to enable RLIMIT_RTPRIO because

     it enables regular users to lockup the machine.
    Up next: 8 other ways for regular users to easily lockup the machine ... "
> I don't know either. In either case the watchdog would probably be

quoted text
> running with the highest rt priority so it should be scheduled in as

> fast in one as in the other. Probably faster when what needs to be

> killed is SCHED_OTHER.

I don't believe that the RTKit watchdog (like Kjetil's Das Watchdog)

takes any action against any SCHED_OTHER process.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev