Lennart Poettering wrote:
> On Mon, 22.06.09 23:46, Jörn Nettingsmeier (nettings@email-addr-hidden-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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 23 12:15:04 2009
This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 12:15:04 EEST