[pulseaudio-discuss] rtkit: add pid as argument
m.b.lankhorst at gmail.com
Sat Apr 24 17:30:35 PDT 2010
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
> 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.
More information about the pulseaudio-discuss