linuxaudio.org

Lennart Poettering wrote:

quoted text
> On Mon, 22.06.09 23:46, Jörn Nettingsmeier (nettings@folkwang-hochschule.de) wrote:

>

>>> What is so difficult to understand that rtkit is not intended to be a

>>> solution for hardcore rt users?

>>>

>>> rtkit is not for you!

>>>

>>> Let me repeat this:

>>>

>>> RTKIT IS NOT FOR YOU!

>> this is getting childish. my claim is: if you give rt to a user, you

>> enable him to fuck the machine up. that's a law of nature. you can do

>> all kinds of very clever things and try to have a very fast watchdog,

>> but it doesn't prevent abuse.

>

> That is simply bogus.

>

> With the reset-on-fork kernel patch in place you can perfectly

> supervise an RT process and it cannot evade you. If the system becomes

> unresponsive (which is all that we try to detect), then we can

> demote/kill everyone who's misbehaving.

you don't need to fork in order to do wreak havoc.

how do you make sure you know which processes (i.e. which executables)

deserve rt rights? hash them?

and whatever you do, the moment the user loads a user-defined plugin

from a user-controlled location (such as a privately installed LADSPA

plugin), you are utterly hosed.
or am i missing something fundamental here? in which case please

enlighten me.
btw, i'm not quite sure what RTLIMIT_RTTIME is supposed to do. you

define a maximum amount of time that can be spent in rt mode, per user?

or per process? or per group?

if per user, how is scheduling fairness accomplished? does the first rt

process grab as much as it wants, and then another rt process gets

demoted by rtkit because the user used up their rt slice?
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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