[pulseaudio-discuss] rtkit: add pid as argument

[Lennart Poettering]

On Sun, 25.04.10 02:30, Maarten Lankhorst (m.b.lankhorst at gmail.com) wrote:

> >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.

OK, I think I underfstand.

> 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. ;)

Well, Linux is not too much different there, unless rtkit enforces some
policy on handing out RT.
 
> >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.

Oh, actually rtkit is not PA only. I do encourage use in other
applications, and I know some already do. rtkit is supposed to be a way
that user software can acquire RT priv safely and while being
supervised, regardless if that user software is PA or something else.

> 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. :)

Well, my reluctance was not really based on security concerns.

> >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.

OK, I am convinced. ;-)

And yes, your use of rktit certainly makes a lot of sense.

Patch looks goot to me. But could you fix one thing: I think
MakeThreadRealtimeWithPID() (or something like tht) would be a better
name than MakeThreadRealtime2(). After examples like wait(), wait3() and
wait4() in Linux, I cannot say I am a big fan of numbering function
calls. ;-)

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4