[pulseaudio-discuss] rtkit: add pid as argument

[Maarten Lankhorst]

Hello Lennart,

On 25-04-10 01:42, Lennart Poettering wrote:
> On Sat, 24.04.10 01:18, Maarten Lankhorst (m.b.lankhorst at gmail.com) wrote:
>
>    
>> I'm not sure if I have the right mailing list, since there doesn't
>> appear to be a a mailing list for rtkit.
>>
>> This is a patch that would allow you to set the realtime priority
>> for another process then the one calling rtkit over dbus. This can
>> be useful for a 'setsched' like utility, or for wine. Extra
>> validation on the given pid isn't needed, since verify_process_user
>> will do this anyhow.
>>      
> Hmm, while I am not strictly against this I don't really see the use for
> this. The primary reason I came up with rtkit was to allow us to ship PA
> and similar software with RT privs out-of-the-box and strictly control
> access to RT for that. A command line tool like you seem to suggest does
> not really fit into that "out-of-the-box" scheme.
>
> What concerns me a bit here is that RT programs must be written in an
> RT specific style to make sense. That means they must internally know
> which threads to make RT and which ones not, and when. From the
> "outside" of the codebase that is difficult to control, especially since
> information about threads in processes is not really available from the
> outside on Linux (yes, you can find out about them, but you don't really
> know which one is which...).
>    
Well, the use case would be wine's wineserver. On windows programs 
usually set audio threads to THREAD_PRIORITY_TIME_CRITICAL to indicate 
that they have to have a certain priority. But in windows thread handles 
are global, so doing it inside wine's 'ntdll' library wouldn't make much 
sense, since the request to set the priority would go to wineserver 
first, since there's no way to tell from inside a wine program to tell 
which handle corresponds to the thread, or even if that handle is local 
or not. Wineserver controls this information so all requests that 
involve handles involve a wineserver call, in general. So racing cannot 
happen, because wineserver is the only one making the requests.

If those applications would try to do bad things on windows xp you could 
lock up the entire system, since it will not reset the scheduler, even 
if that means on a single core system that it will lock everything else 
out. ;)

> Also, RT programs must be RT from beginning of their RT code to the
> end. If you control their RT scheduling only from the outside this is
> almost definitely racy. If you want to control RT privs from outside of the
> process, then the only non-racy way would be to use inheriting across an
> exec(), which however is something rtkit explcitily prohibits.
>    
> I am also wondering how many people would use this functionality instead
> of the lower level, chrt(1) command?
>    
Well, I'm aware rtkit is pulseaudio only, but there have been some 
people who already use SCHED_RR with wine, mainly people who use it for 
professional audio with jack or asio. This patch is not officially part 
of wine, because of the possibility of abuse and forkbombs. Out of tree 
patches are used.

For wine I already had a patch that used rtkit, but it queued a 
wine-rtkit-specific apc to the thread involved, and involved opening 
dbus inside wine's ntdll, which is not really a good place to do it. And 
not likely to get accepted to wine as result.
> So, as mentioned I am not strictly against this, but I'd be interested
> to hear some good use cases for this, simply because I fear that people
> might otherwise be invited to write improper RT code.
>    
I'd like to point out I already had it working without the patch, but 
the methods I used were a lot racier and uglier, because I had to queue 
the request to the target thread involving a wine-rtkit-specific apc. Of 
course this was just a proof of concept, so I wanted a cleaner solution. 
You could also write a chrt now that doesn't require cap_sys_nice to 
use, but this patch was mainly written wine.

What would prevent a process from using ptrace on another process with 
the same uid, and then request realtime priorities from it? I just want 
it somewhat easier, in a way that I can use it in wine. :)
> So, convince me!
>    
I'm not sure how this patch would encourage writing improper rt code, 
since you could just use rtkit.c in your project for rt already. This 
will just let wine benefit from the existing functionality in a saner way.

Cheers,
Maarten