[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Lennart Poettering]

Heya,

Just a quick announcement:

I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.

So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

So what's so fancy about it? Nothing. Except that is hopefully a good
solution for handing out RT scheduling and is also actually secure.

What's wrong with using RLIMIT_RPRIO? The simple fact that we cannot
enable that by default since it basically empowers the user to freeze
the machine. Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

But what's wrong with relying on RLIMIT_RTTIME? Being a process limit
it can very easily be circumvented for freezing the machine by
combining an RT busy loop with a fork bomb.

But what's wrong with relying on on a canary watchdog to avoid
freezing systems? It's racy: an evildoer could fork more quickly than
the canary watchdog daemon could demote its children. So a canary is
not really a protection against a frozen system.

Why not use cgroups for this? Because it's simply a horrible API, and
using this for media applications has non-obvious consequences on
using cgroups for their originally intended purpose -- which are
containers.

So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31. You
can set that flag when entering SCHED_RR scheduling and this will then
make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand out
RT to a process we can be sure it won't "leak", and if we decide to
take it away again we can be sure we can do that without having to be
afraid of races around forking.

rtkit enforces limits on the the number of threads/processes/users
that get RT sched. It also does rate limiting, and calls into
PolicyKit before handing out RT. Finally, as extra a-posteriori
protection it also includes a canary watchdog.

So what does that mean for you?

If you don't do RT development or doing RT development only for
embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy
then it doesn't mean anything for you.

However, if you are a desktop developer interested to get your stuff
working out-of-the-box on modern distributions then you should think
about calling into RealtimeKit for acquiring RT scheduling.
RealtimeKit has a trivial API, to make a thread SCHED_RR it's just one
D-Bus method you need to call. You can either code that call yourself
or alternatively just copy the reference client implementation rtkit
includes into your sources:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.h
http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c

For more information see this:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

So yepp, it would be great if folks would adopt this in their apps, so
that a user doesn't need to know about all those Unix intricacies such
as resource limits and so on, but still get good perfomance in his
media applications by default.

This is now in Fedora Rawhide which will still take a few months to be
released as F12. The other distros probably need a bit more time for
this. This means this is not a burning issue yet, so this is mostly
intended as a heads-up right now. Unless of course you are one of
those cool dudes who are living on the bleeding edge.

Packagers, you might want to steal this .spec file for you work:

http://cvs.fedoraproject.org/viewvc/devel/rtkit/rtkit.spec?revision=1.1&view=markup

Questions?

Lennart

[Ralf Mardorf]

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

Is it proved not to negative affect MIDI jitter? It seems to be an up
and down with kernel versions. Audio always seems to be fine, while MIDI
jitter increases or decreases randomly from version to version. It
should been proved that it won't have unwanted effects, before it's
included to the rt patch's tree. I'm a user only, it's not an
assumption, just a question.

Best,
Ralf

[Lennart Poettering]

Post by Ralf Mardorf

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

Is it proved not to negative affect MIDI jitter? It seems to be an up
and down with kernel versions. Audio always seems to be fine, while MIDI
jitter increases or decreases randomly from version to version. It
should been proved that it won't have unwanted effects, before it's
included to the rt patch's tree. I'm a user only, it's not an
assumption, just a question.

This should have no such impact. The flag is only checked for on
fork(), i.e. almost never.

Lennart

[Ralf Mardorf]

Post by Lennart Poettering

Post by Ralf Mardorf

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

Is it proved not to negative affect MIDI jitter? It seems to be an up
and down with kernel versions. Audio always seems to be fine, while MIDI
jitter increases or decreases randomly from version to version. It
should been proved that it won't have unwanted effects, before it's
included to the rt patch's tree. I'm a user only, it's not an
assumption, just a question.

This should have no such impact. The flag is only checked for on
fork(), i.e. almost never.
Lennart

That's good Lennart. Thank you for the information. I always fear that
things can have impact to the poor relation rt-MIDI.

Best,
Ralf

[Chris Cannam]

Post by Lennart Poettering
Questions?

Is it safe to assume that the PulseAudio libraries will use this
method to acquire real-time scheduling for the audio callback thread
of any application that uses the PulseAudio callback API directly?


Chrs

[Lennart Poettering]

Post by Chris Cannam

Post by Lennart Poettering
Questions?

Is it safe to assume that the PulseAudio libraries will use this
method to acquire real-time scheduling for the audio callback thread
of any application that uses the PulseAudio callback API directly?

Uh. I thought about that. Not sure if we really should do that
though. In many cases, the app's IO callback might not really be that
well suited for execution in RT. And then it might end up being killed
by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
and we could just make all IO threads RT at prio 1 or so. I am a bit
afraid that such a thing might backfire and we fuck up the scheduling
for everyone else too.

I really don't know. Maybe just make it easily accessible would be a
good idea, but not enable by default. But OTOH RT is not a magic wand,
so I wouldn't want to create the illusion that just making a broken
app RT fixes all issues magically.

Lennart

[Chris Cannam]

Post by Lennart Poettering

Post by Chris Cannam
Is it safe to assume that the PulseAudio libraries will use this
method to acquire real-time scheduling for the audio callback thread
of any application that uses the PulseAudio callback API directly?

Uh. I thought about that. Not sure if we really should do that
though. In many cases, the app's IO callback might not really be that
well suited for execution in RT. And then it might end up being killed
by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
and we could just make all IO threads RT at prio 1 or so. I am a bit
afraid that such a thing might backfire and we fuck up the scheduling
for everyone else too.

That's a fair point. Given history, I expect the last thing we want
is to create an impression that providing good audio services in a
distribution must be seriously detrimental to anyone's server
workload.

For my part, I have applications that use JACK if available, falling
back first to PulseAudio's callback API and then to ALSA via
PortAudio, using effectively the same callback code in each case.

I'd be happy to add another couple of lines to improve the scheduling
of my callback thread when using Pulse in a "desktop" context. A bit
more code is no problem; there's already quite a lot of logic there:
arguably too much, but I don't want to lose PortAudio because it
provides portability, I don't want to lose the direct Pulse layer
since it works best of the three for me in most desktop situations,
and I don't want to lose JACK because, well, it's JACK.

But I probably would mind having to explicitly include and link
against DBUS libraries. I appreciate that my code is already using
DBUS somewhere under the covers, but another explicit build dependency
for two lines of code doesn't seem ideal. So a way to do this through
the PulseAudio API would be very welcome to me.


Chris

[Lee Revell]

Post by Lennart Poettering

Post by Chris Cannam

Post by Lennart Poettering
Questions?

Is it safe to assume that the PulseAudio libraries will use this
method to acquire real-time scheduling for the audio callback thread
of any application that uses the PulseAudio callback API directly?

Uh. I thought about that. Not sure if we really should do that
though. In many cases, the app's IO callback might not really be that
well suited for execution in RT. And then it might end up being killed
by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
and we could just make all IO threads RT at prio 1 or so. I am a bit
afraid that such a thing might backfire and we fuck up the scheduling
for everyone else too.

Sorry if this is too many questions, i have read the Pulse code and
the LKML thread and was wondering:

I was under the impression that SCHED_RESET_ON_FORK was needed to
safely enable RT mode in Pulse because Pulse runs untrusted client
code. If that's not the case then why is it needed?

What does RealtimeKit set the RR interval to? IIRC the default is
100ms, seems like this could cause desktop interactivity issues. What
determines the upper bound on the amount of work Pulse's RT threads
can do?

Without mlock(), what happens when the SCHED_RR thread starts taking
page faults? AFAICT, it will be scheduled out, but as long as it has
time slice left, it will be immediately rescheduled.

Lee

[Lennart Poettering]

Post by Lee Revell

Post by Lennart Poettering
Uh. I thought about that. Not sure if we really should do that
though. In many cases, the app's IO callback might not really be that
well suited for execution in RT. And then it might end up being killed
by RLIMIT_RTTIME or so. Dunno. Maybe that would not even be a problemn
and we could just make all IO threads RT at prio 1 or so. I am a bit
afraid that such a thing might backfire and we fuck up the scheduling
for everyone else too.

Sorry if this is too many questions, i have read the Pulse code and
I was under the impression that SCHED_RESET_ON_FORK was needed to
safely enable RT mode in Pulse because Pulse runs untrusted client
code. If that's not the case then why is it needed?

PA runs as user process. That's why this is needed. If a process is a
user process the user can do with it whatever he wants, in the PA case
this is even especially easy since all he needs to do is load some
module he wrote into the daemon.

Post by Lee Revell
What does RealtimeKit set the RR interval to? IIRC the default is
100ms, seems like this could cause desktop interactivity issues. What
determines the upper bound on the amount of work Pulse's RT threads
can do?

We leave the RR interval at the default. I have some doubts that
fiddling with the RR interval is a good idea. First of all the API to
do that is messy and changed across kernel versions a few
times. Secondly, rtkit is not really useful beyond desktop media
stuff, and a desktop media application that wants to take a
substantial CPU share while being RT (where the interval would matter)
is uh, suspicious to say the least.

The CPU time is limited by RLIMIT_RTTIME and also simply by the fact
that on system overload (the definition of which can be configured in
rtkit) the RT threads are demoted.

I mean, if fiddling with the rr interval turns out to be necessary, we
can still add an interfaces this. Dunno. I kinda have the idea that
this is mostly a theoretical question anyway, since at least in the
audio case in the usual case only one process is runnable anyway, ...

If someone wants this, and has a good use case we can certainly add
this, but I'd not think too much about stuff we don't need right now.

Post by Lee Revell
Without mlock(), what happens when the SCHED_RR thread starts taking
page faults? AFAICT, it will be scheduled out, but as long as it has
time slice left, it will be immediately rescheduled.

To my knowledge while the process is waiting for IO to complete for
the page fault other processes will be scheduled. The time
spent in page faults is not counted as process time.

Lennart

[Paul Davis]

Post by Lennart Poettering
Heya,
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions. Alternatively, one could see
it as a baroque mechanism designed to solve to solve a problem that
really needs a much more sophisticated solution (i.e. better
scheduling policies). Either way, it seems like something that makes
things more complex on every level, not less. Take a look at the code
in libjack/thread.c and compare and contrast what is necessary to get
a realtime thread on Linux (already) compared to OS X. You're adding a
new API for this that will not be backwards compatible beyond a kernel
change that has only just been made. I cannot imagine wanting to use
this mechanism. You also seem to have assumed that everyone agrees
that SCHED_RR is the correct policy, rather than SCHED_FIFO.
Reasonable people still disagree about this. Finally, as Chris said -
many of us are writing apps that target multiple platforms, and adding
a new dependency on non-POSIX systems like DBus in order to get done
things that are supposed to be possible with the POSIX API ... well,
it gives some of us a slightly wierd feeling at the very least.

--p

[Lennart Poettering]

Post by Paul Davis

Post by Lennart Poettering
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions.

Simpler solutions? I am listening! What would a "simpler solution" be,
that doesn't suffer by all the issues I pointed out in the README?

Also, what's baroque with this? I mean, really, this offers an API of
two tiny functions. Not sure why you'd call that baroque?

Post by Paul Davis
Alternatively, one could see it as a baroque mechanism designed to
solve to solve a problem that really needs a much more sophisticated
solution (i.e. better scheduling policies).

Dunno. SCHED_ISO would certainly be nice, but having that wouldn't
solve the problem really either. Also in the end you need to supervise
RT processes anyway, which is heavily bound to admin policy and
will hence probably always require some userspace part.

And rtkit is just a tiny piece of software that only requires minimal
additions to client code to be useful. So if one day it turns out it
won't be necessary anymore then we can simply remove without much
hassle. This doesn't have to be a solution for the eternity.

Post by Paul Davis
Either way, it seems like something that makes things more complex
on every level, not less.

Ah yeah? How so? What's complex? Adding a single #ifdef'ed fucntion
call to your code? I mean, really, there's not much left that could be
simpler than that.

Post by Paul Davis
Take a look at the code in libjack/thread.c and compare and contrast
what is necessary to get a realtime thread on Linux (already)
compared to OS X.

Uh? I see one function call for mach's setThreadToPriority
vs. .... one function for pthread_setschedparam(). Uh? Where's the
practical difference?

Post by Paul Davis
You're adding a new API for this that will not be backwards
compatible beyond a kernel change that has only just been made.

So what? How does that matter? New features you only get with new
code.

And it's not that adding support for rtkit to some software would
break anything that worked previously. RLIMIT_RTPRIO will still work
just fine, if people set it. All rtkit is about is that we can enable
RT scheduling for media applications out-of-the-box on newer Linux
distributions. If 'out-of-the-box' doesn't matter to you then
fine, I am pretty sure that distributors who ship your software do
care about it. I am pretty sure that in Fedora we would simply patch
jack_acquire_real_time_scheduling() to query rtkit if
pthread_setschedparam() fails with EPERM. It's a tiny
patch. However, I really don't see why you wouldn't want to merge a
jack patch like that to jack's official sources as long as it is a
compile-time option. I am pretty sure the distributors would be
thankful for that.

Post by Paul Davis
I cannot imagine wanting to use this mechanism. You also seem to
have assumed that everyone agrees that SCHED_RR is the correct
policy, rather than SCHED_FIFO.

If people can make a good case for SCHED_FIFO, then fine, we can add
that to rtkit.

Personally, I believe that RR vs. FIFO is not so much a decision that the
programmer should make. I think this is more a decision for the admin,
because this influences fairness between consumers of RT.

Post by Paul Davis
Reasonable people still disagree about this. Finally, as Chris said
- many of us are writing apps that target multiple platforms, and
adding a new dependency on non-POSIX systems like DBus in order to
get done things that are supposed to be possible with the POSIX API
... well, it gives some of us a slightly wierd feeling at the very
least.

Uh. First of all, it's hard to find a POSIX system these days that
doesn't have D-Bus installed. All big distributions ship it. All big
desktop environments require it. Even non-Linux systems that are from
the last 5 years ship it. To find a system that lacks D-Bus you need
to go to niche distributions which are specifically designed to avoid
sytems such as D-Bus. But I seriously doubt they really matter.

D-Bus is simply an API for IPC, one that happens to have an adoption
of 100% on relevant POSIX implementations. If you try to avoid D-Bus
for IPC when coding for those systems then all you do is reinventing
the wheel over and over, duplicating a substantial amount of code, and
potentially buggy code. At this point in time it's not D-Bus that is
bloat but it is the applications that still implement their own
non-trivial IPC system that include unnecessary bloat.

Finally, I believe your insisting on POSIX is a lost cause anyway,
because it is a fictitious OS interface. It's a good guideline, but
limiting yourself to it will limit the usefulness of your application
drastically because you don't make use of a real operating system's
feature set anymore, but to one that does only exist as an idea, as
the least common denominator of a few OSes that are already quite aged
these days. Also, at an ironic side note, your own
jack_acquire_real_time_scheduling() implementation as one example is
not even POSIX compliant. You print pthread_t as a %d. POSIX is pretty
explicit that pthread_t does not have to be an int, not even an
arithemtic type, but could be a struct.

In summary: I am not asking you to adopt this replacing some of your
current code. All I kindly ask for is to ease the distributors life by
adding a tiny bit of fallback code that does a tiny call into rtkit in
case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
&& HAVE_DBUS and is also contorollable as a compile-time configure
option.

Lennart

[Paul Davis]

Post by Lennart Poettering

Post by Paul Davis

Post by Lennart Poettering
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions.

Simpler solutions? I am listening! What would a "simpler solution" be,
that doesn't suffer by all the issues I pointed out in the README?
Also, what's baroque with this? I mean, really, this offers an API of
two tiny functions. Not sure why you'd call that baroque?

the API is simple. the implementation that the API sits on top of it
baroque. not yours, necessarily, but the combination of RTKit and
Ingo's patch. Baroque doesn't necessarily mean "huge, vast and
incomprehensible". it can just mean "overly intricate for the task at
hand".

i definitely led you astray with the reference to the jack source
code. firstly because you seem to have imagined that by mentioning the
use of POSIX i was making some kind of claim about POSIX correctness -
not sure what kind of game that it is. but secondly and more
importantly because the code now looks reasonably clean as a result of
me ditching all the crap that we needed on various older versions of
linux. yes, it is indeed now just as simple as OS X. in the code only,
of course. i had forgotten to check the current state of things before
referring to it.

Post by Lennart Poettering
All I kindly ask for is to ease the distributors life by
adding a tiny bit of fallback code that does a tiny call into rtkit in
case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
&& HAVE_DBUS and is also contorollable as a compile-time configure
option.

so, sched_setschedparam(), a documented, implemented and demonstrably
functional call fails in some cases. and your proposal is to replace
this well-established API with a new API that doesn't actually
accomplish anything new except *WORKING* ? i'm sorry but to me this is
just absurd. the call is there, it works (for a user with certain
priviledges granted), and has a reasonably long pedigree. why should
fixing the problem with priviledge granting be accomplished with a
different call to get the same scheduling priority, a call that relies
on new kernel functionality that isn't necessary for the sched_sp()
approach? this is applying a band-aid to a deeper solution, and its
because of this that its hard to support it.

go and ask linus or ingo and/or whoever is deputized to handle (a)
scheduling and (b) priviledge control mechanisms. if they come back
and say "we think this is an appropriate solution and we don't intend
to address this any further in terms of kernel mechanisms" then the
conversation moves on to the next step - why are distributions not
being more creative with the priviledge granting mechanism that is
already in place? my reading of ingo's patch is that its mechanism,
not policy (as usual for the kernel), and its really *mostly*
duplicating facilities that are already intended to be accessed via
sched_setschedparam(). apparently, you feel otherwise. the thing is
lennart that the kernel guys and others interested in regular user
access to SCHED_(!OTHER) put a lot of effort into the current rlimit
mechanism as the appropriate solution. none of the mainstream
distributions have bothered to make it configurable, usable etc. etc.
fixing that by creating a new API just seems ... odd at best, and
counter-productive at worst.

--p

[Lennart Poettering]

Post by Paul Davis

Post by Lennart Poettering

Post by Paul Davis

Post by Lennart Poettering
So what does this do? It's a simple policy daemon that hands out
SCHED_RR scheduling to normal user processes/threads that ask for it.

This appears to be a baroque mechanism designed to solve a problem
suspectible to vastly simpler solutions.

Simpler solutions? I am listening! What would a "simpler solution" be,
that doesn't suffer by all the issues I pointed out in the README?
Also, what's baroque with this? I mean, really, this offers an API of
two tiny functions. Not sure why you'd call that baroque?

the API is simple. the implementation that the API sits on top of it
baroque. not yours, necessarily, but the combination of RTKit and
Ingo's patch. Baroque doesn't necessarily mean "huge, vast and
incomprehensible". it can just mean "overly intricate for the task at
hand".

It's me who wrote the kernel patch actually. And after discussing my
plans and the pros and cos with a few kernel/rt folks the patch went into
Ingo's tree.

The patch didn't come out of the blue sky and then Lennart came around
and wrote rtkit using it. No. Instead I have been discussing the issue
we fix with rtkit with a couple of people off and on for quite some
time now. And a couple of weeks ago I decided to actually to do
something about it and wrote this little patch accompanied by this
little userspace support for it which is going by the name of rtkit.

This is the patch btw:

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=ca94c442535a44d508c99a77e54f21a59f4fc462

Have you actually read rtkit's README file? This goes a bit into
details about the reasons to solve the issues this way.

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

Post by Paul Davis

Post by Lennart Poettering
All I kindly ask for is to ease the distributors life by
adding a tiny bit of fallback code that does a tiny call into rtkit in
case sched_setschedparam() fails with EPERM and is #ifdef as __linux__
&& HAVE_DBUS and is also contorollable as a compile-time configure
option.

so, sched_setschedparam(), a documented, implemented and demonstrably
functional call fails in some cases. and your proposal is to replace
this well-established API with a new API that doesn't actually
accomplish anything new except *WORKING* ?

No. I am not talking about *replacing*. I have asked for adding
support for rtkit to it.

Post by Paul Davis
i'm sorry but to me this is just absurd. the call is there, it works
(for a user with certain priviledges granted), and has a reasonably
long pedigree. why should fixing the problem with priviledge
granting be accomplished with a different call to get the same
scheduling priority, a call that relies on new kernel functionality
that isn't necessary for the sched_sp() approach? this is applying a
band-aid to a deeper solution, and its because of this that its hard
to support it.

The thing is that we cannot safely hand out RT privileges to user
processes without doing acess/rate limiting, watchdog support, calls
into policy systems and so on and so on.

Post by Paul Davis
go and ask linus or ingo and/or whoever is deputized to handle (a)
scheduling and (b) priviledge control mechanisms. if they come back
and say "we think this is an appropriate solution and we don't intend
to address this any further in terms of kernel mechanisms" then the
conversation moves on to the next step - why are distributions not
being more creative with the priviledge granting mechanism that is
already in place? my reading of ingo's patch is that its mechanism,
not policy (as usual for the kernel), and its really *mostly*
duplicating facilities that are already intended to be accessed via
sched_setschedparam().

You are really misunderstanding the situation here. Firstly, *I* wrote
the patch, and *I* was the one pushing this through. Secondly, this is
not coming out of the blue sky, but this is the result of discussions
with the RT folks, both inside RH and outside of RH. (which is
partially documented in the acked-by/signed-off-by of the patch, just
have a look!)

Now, if you think you have a better insight into how things should be
done than all of us, then hey, be my guest, why don't you make some
*proper* suggestions how an alternative should be looking like? Asking
for "creative use" and giving the fault to the distributors just
doesn't cut it.

The big problem with RLIMIT_RTPRIO is that it is vulnerable to a
combined fork bomb/busy loop attack. Which I btw documented in the
README (which I figure you didn't read?). Because that is the way it
is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What
did happen is that some distros added an ugly unsecure kludge by
adding "jackuser" group or suchlike that you can add a user to that
had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also
leaves the "out-of-the-box" issue unresolved.

The low-level sched_setschedparam() syscall is a basic primitive
that can be used as building block for implementing RT
in userspace. It does only minimal policy leaving all the rest for
userspace, as it should be. Nothing in POSIX however says that this is
the API that applications should rely on to use, behind which all
security policy decisions are hidden.

Post by Paul Davis
apparently, you feel otherwise. the thing is lennart that the kernel
guys and others interested in regular user access to SCHED_(!OTHER)
put a lot of effort into the current rlimit mechanism as the
appropriate solution.

You seem to suggest that I wasn't talking to the kernel folks before I
do something like this. That is wrong. This announcement of mine was
just the last step in doing all this, not the first step.

Post by Paul Davis
none of the mainstream distributions have bothered to make it
configurable, usable etc. etc.

Yes, and there are good reasons for it (see above).

Gah. This discussion is so pointless. If you don't want to use in
Jack then fine. The distributions will ship the API and if you don't
make use of it, so be it. It's certainly disappointing, but ultimately
it's not my problem.

No hard feelings,

Lennart

[Paul Davis]

Post by Lennart Poettering

Post by Paul Davis
so, sched_setschedparam(), a documented, implemented and demonstrably
functional call fails in some cases. and your proposal is to replace
this well-established API with a new API that doesn't actually
accomplish anything new except *WORKING* ?

No. I am not talking about *replacing*. I have asked for adding
support for rtkit to it.

this is quibbling over details. sched_setschedparam() *should* work -
its documented as working, the kernel and the higher levels of the OS
provide a mechanism to grant priviledge but ... it isn't. so the fix
is to add a new call? is this really what are you saying?

Post by Lennart Poettering
The thing is that we cannot safely hand out RT privileges to user
processes without doing acess/rate limiting, watchdog support, calls
into policy systems and so on and so on.

hence my comment: RTKit is a baroque solution to a problem that really
needs a much more sophisticated solution.

Post by Lennart Poettering

Post by Paul Davis
go and ask linus or ingo and/or whoever is deputized to handle (a)
scheduling and (b) priviledge control mechanisms. if they come back

Now, if you think you have a better insight into how things should be
done than all of us, then hey, be my guest, why don't you make some
*proper* suggestions how an alternative should be looking like? Asking
for "creative use" and giving the fault to the distributors just
doesn't cut it.

you seem to have missed the fact that we went through just such a
discussion about 3 years ago when RLIMIT_RTPRIO was first added. there
was wide discussion about how to do this. there was specific
expectation that distros would provide mechanisms for enabling (and
disabling) its use. it was *explicitly* intended to be
group-controllable. now you inform us that "it has been decided" that
this is bad design. ok, we learn from mistakes and we move on. but
everytime this happens, it makes it harder to trust the next choice.
and what happened after the last decision was made about how to
support/configure this ...

almost every media-centric distro enables it out of the box (by user
group); no "mainstream" distro does. nobody has created any
user-accessible mechanisms to configure it. everything that expected
to happen after it went into the kernel has not happened. distro
maintainers argue that its a security/robustness problem, and i'm not
arguing with this. but there are many things you can configure on any
mainstream distro that create security/robustness problems, this one
just happens to come with only a text file to configure it and no
support from any distro (media centric ones included).

Post by Lennart Poettering
The big problem with RLIMIT_RTPRIO is that it is vulnerable to a
combined fork bomb/busy loop attack. Which I btw documented in the
README (which I figure you didn't read?). Because that is the way it
is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What
did happen is that some distros added an ugly unsecure kludge by
adding "jackuser" group or suchlike that you can add a user to that
had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also
leaves the "out-of-the-box" issue unresolved.

except that i could find you posts from people on the l-k mailing list
3 years ago that argued precisely the opposite: that this was
*exactly* the solution that was in keeping with other kernel security
policy/design issues.

Post by Lennart Poettering
You seem to suggest that I wasn't talking to the kernel folks before I
do something like this. That is wrong. This announcement of mine was
just the last step in doing all this, not the first step.

so, who of the half-dozen people from the LAD world who contributed to
the discussion that led to RLIMIT_RTPRIO did you include? there seem
to be some remarkably short-lived memories in kernel land if people
there are so ready to support what is essentially a workaround to what
used to be the Right Answer.

Post by Lennart Poettering
Gah. This discussion is so pointless. If you don't want to use in
Jack then fine. The distributions will ship the API and if you don't
make use of it, so be it. It's certainly disappointing, but ultimately
it's not my problem.

Lennart, I am not *that* self-centered. I've been confronting issues
with Linux support for RT for more than 10 years. I don't give a damn
about whether JACK uses this or not. What I care about is the more or
less complete failure of the Linux community (by which I include
myself, and all of the rest of us) to come with solutions to this
problem that actually work and will be supported over more than a
couple of years before we move on to the "next approach". I totally
understand the goal you have with RTKit, and I applaud you strongly
for trying to get this situation fixed. But your solution appears out
of the blue in front of one of the two communities most affected by
this stuff, and basically ditches the last solution, in which we were
quite involved and invested, for a totally different (service/IPC
based) solution. Can you not understand why there is some resistance?

[Lennart Poettering]

Post by Paul Davis

Post by Lennart Poettering

Post by Paul Davis
so, sched_setschedparam(), a documented, implemented and demonstrably
functional call fails in some cases. and your proposal is to replace
this well-established API with a new API that doesn't actually
accomplish anything new except *WORKING* ?

No. I am not talking about *replacing*. I have asked for adding
support for rtkit to it.

this is quibbling over details. sched_setschedparam() *should* work -
its documented as working, the kernel and the higher levels of the OS
provide a mechanism to grant priviledge but ... it isn't. so the fix
is to add a new call? is this really what are you saying?

What I am saying is that the current system is too "binary": Either
you have RT sched and then for *everything*. Or you haven't, and then
you haven't got it for *anything*.

For the desktop case you need something in between: RT that cannot be
misused, basically. Doing that securely is particularly hard, which is
the reason why we still haven't got it. Only if this solution "in
between" is found, we can enable RT by default for normal users.

Now, a lot of suggestions have been made to fix this over the
years. RLIMIT_RTPRIO, isochronous scheduling, using cgroups and so
on. All of those solutions turned out to be suboptimal and never got
adopted by the distros in a wide scale, or haven't even made into the
kernel.

Now, rtkit is another approach, a lot simpler, and something that was
in the end implementable in just a few days of work, with only minor
changes necessary on the kernel side. Something "good enough", to for
being adopted for the next few years.

Since it enforces all kinds of policy on its clients this little tool
lives in userspace, so that the policy parameters don't have to be
encoded in the kernel.

Now, as mentioned rtkit might not be a solution for eternity. However
it is a solution that should be good enough for quite some time.

Maybe one day we get isochronous scheduling in the kernel with all the
"adding up" issues fixed in a clean way. That day we can kill rtkit
again from the distros. Should be easy enough given how minimal the
interfacing between apps and rtkit actually is.

Post by Paul Davis

Post by Lennart Poettering

Post by Paul Davis
go and ask linus or ingo and/or whoever is deputized to handle (a)
scheduling and (b) priviledge control mechanisms. if they come back

Now, if you think you have a better insight into how things should be
done than all of us, then hey, be my guest, why don't you make some
*proper* suggestions how an alternative should be looking like? Asking
for "creative use" and giving the fault to the distributors just
doesn't cut it.

you seem to have missed the fact that we went through just such a
discussion about 3 years ago when RLIMIT_RTPRIO was first added. there
was wide discussion about how to do this. there was specific
expectation that distros would provide mechanisms for enabling (and
disabling) its use. it was *explicitly* intended to be
group-controllable. now you inform us that "it has been decided" that
this is bad design. ok, we learn from mistakes and we move on. but
everytime this happens, it makes it harder to trust the next choice.
and what happened after the last decision was made about how to
support/configure this ...

I wasn't around at those discussions back then, and neither was I in
the position I am in now. My views on that story is that back then RT
for audio was only relevant for audio _production_, and the folks
involved didn't see a problem with asking the user to become a member
of some group.

Nowadays, RT for audio is relevant for the normal desktop use case,
too. And asking for group membership or some other way to bump
RLIMIT_RTPRIO is very bad UI. Almost no user can make a properly
informed decision before agreeing to that.

So, the situation changed since then. What was a bit of a niche
feature in those days is now something that should be exposed by
default. And this asks for reinvestigating the whole story, and making
RT less "binary", as mentioned above, and supervising its use.

Post by Paul Davis

Post by Lennart Poettering
The big problem with RLIMIT_RTPRIO is that it is vulnerable to a
combined fork bomb/busy loop attack. Which I btw documented in the
README (which I figure you didn't read?). Because that is the way it
is, we, the distributors, never enabled RLIMIT_RTPRIO by default. What
did happen is that some distros added an ugly unsecure kludge by
adding "jackuser" group or suchlike that you can add a user to that
had RLIMIT_RTPRIO set. But that's hardly a clean solution, and also
leaves the "out-of-the-box" issue unresolved.

except that i could find you posts from people on the l-k mailing list
3 years ago that argued precisely the opposite: that this was
*exactly* the solution that was in keeping with other kernel security
policy/design issues.

Back then desktop folks were not involved. polkit was not around and
it was a bit of a nichey special-purpose feature. All that changed
now.

Post by Paul Davis

Post by Lennart Poettering
You seem to suggest that I wasn't talking to the kernel folks before I
do something like this. That is wrong. This announcement of mine was
just the last step in doing all this, not the first step.

so, who of the half-dozen people from the LAD world who contributed to
the discussion that led to RLIMIT_RTPRIO did you include? there seem
to be some remarkably short-lived memories in kernel land if people
there are so ready to support what is essentially a workaround to what
used to be the Right Answer.

The kernel patch was discussed publicly on lkml. I discussed this on
IRC with a couple of folks involved, whose OK I was looking for.

Also, the kind of anti-desktop fud war that errupted as a result to
this little announcement on lad is not really a convincing argument for
always keeping all of LAD in the loop.

Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Paul Davis
I cannot imagine wanting to use this mechanism. You also seem to
have assumed that everyone agrees that SCHED_RR is the correct
policy, rather than SCHED_FIFO.

If people can make a good case for SCHED_FIFO, then fine, we can add
that to rtkit.
Personally, I believe that RR vs. FIFO is not so much a decision that the
programmer should make. I think this is more a decision for the admin,
because this influences fairness between consumers of RT.

It is, ultimately, a decision for the _user_ to make. RealtimeKit should
also take that into account.

As a user doing critical audio, say, in a concert situation, I'd require
that my computer's realtime audio tasks can use 99.9% of the cpu for
short amounts of time. I don't care if the rest of the user processes
are momentarily slowed down (up to a point, of course). I would very
much care if my computer, due to a temporary overload, decides to a)
glitch the audio and b) demote the rt process to SCHED_OTHER
permanently. It looks like the RealtimeKit is designed to do exactly
that by default.

If that is the case, how can I regain control of what I can do without
having to resort to extreme cases of root configuration file magic, etc,
etc (what RealtimeKit is supposed to avoid).

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Paul Davis
I cannot imagine wanting to use this mechanism. You also seem to
have assumed that everyone agrees that SCHED_RR is the correct
policy, rather than SCHED_FIFO.

If people can make a good case for SCHED_FIFO, then fine, we can add
that to rtkit.
Personally, I believe that RR vs. FIFO is not so much a decision that the
programmer should make. I think this is more a decision for the admin,
because this influences fairness between consumers of RT.

It is, ultimately, a decision for the _user_ to make. RealtimeKit should
also take that into account.
As a user doing critical audio, say, in a concert situation, I'd require
that my computer's realtime audio tasks can use 99.9% of the cpu for
short amounts of time. I don't care if the rest of the user processes
are momentarily slowed down (up to a point, of course). I would very
much care if my computer, due to a temporary overload, decides to a)
glitch the audio and b) demote the rt process to SCHED_OTHER
permanently. It looks like the RealtimeKit is designed to do exactly
that by default.

By default the watchdog will only become active after 10s of complete
lockup. This should be enough. We can raise it if this turns out to be
necessary, but let's wait for a request based on real-world data
before we do something like that.

Also note that in a case like yours admin and user are usually
identically, so if you don't trust rtkit just bypass it and use
RLIMIT_RTPRIO as it was done before rtkit came into the game.

Post by Fernando Lopez-Lezcano
If that is the case, how can I regain control of what I can do without
having to resort to extreme cases of root configuration file magic, etc,
etc (what RealtimeKit is supposed to avoid).

rtkit only comes into play as last resort when rt is cannot otherwise
be required (at least if developers follow my recommendations from the
README). If the supervised realtime sched that rtkit gives you isn't
good enough, then simply give your application unsupervised RT by
means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

Lennart

[Jörn Nettingsmeier]

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
As a user doing critical audio, say, in a concert situation, I'd require
that my computer's realtime audio tasks can use 99.9% of the cpu for
short amounts of time. I don't care if the rest of the user processes
are momentarily slowed down (up to a point, of course). I would very
much care if my computer, due to a temporary overload, decides to a)
glitch the audio and b) demote the rt process to SCHED_OTHER
permanently. It looks like the RealtimeKit is designed to do exactly
that by default.

By default the watchdog will only become active after 10s of complete
lockup. This should be enough. We can raise it if this turns out to be
necessary, but let's wait for a request based on real-world data
before we do something like that.

this demonstrates nicely that there is no solution to the problem (or
that i don't understand what problem you are trying to solve).

any user that gets rt privileges can DoS the machine. actually, one
person's creative act is another person's DoS :)

if you try to guard against forkbombs, you are obviously under the
illusionary impression that you can guide against malicious users. you
can't. with your new bit of policy, i just write a bomb that eats up
100% for 9.9s, then yields for as long as your daemon needs to be
pacified, then hog the machine again.

so what is this about? rt users want absolute control over their
machine. anybody who can tolerate some arbitrary bits of policy thrown
at them during work is by definition not an rt user.
rt users must be trustable with root access, at least in terms of cpu
governance, which is what rtlimits achivev just fine.

[Lennart Poettering]

Post by Jörn Nettingsmeier
so what is this about? rt users want absolute control over their
machine. anybody who can tolerate some arbitrary bits of policy thrown
at them during work is by definition not an rt user.
rt users must be trustable with root access, at least in terms of cpu
governance, which is what rtlimits achivev just fine.

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!

rtkit is a just missing piece of the puzzle that allows distros to
enable RT by default for their desktop users.

And rtkit doesn't break RLIMIT_PRIO, it isn't even activated when that
is set.

Let me repeat this, too:

RTKIT DOESN'T BREAK RLIMIT_RTPRIO!

It was clearly a bad idea to post about rtkit on lad. It is a big
waste of time fighting this through against all those desktop-haters,
fdo-haters, dbus-haters, who apparently believe I am out to take away
their freedom to run their systems the way want. I really don't need
this shit. The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around.

Lennart

[Jörn Nettingsmeier]

Post by Lennart Poettering

Post by Jörn Nettingsmeier
so what is this about? rt users want absolute control over their
machine. anybody who can tolerate some arbitrary bits of policy thrown
at them during work is by definition not an rt user.
rt users must be trustable with root access, at least in terms of cpu
governance, which is what rtlimits achivev just fine.

What is so difficult to understand that rtkit is not intended to be a
solution for hardcore rt users?
rtkit is not for you!
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.

my point is: since the rt user is locally trusted, you can just as well
grant static rt rights using the rtlimits approach. if the user is not
to be trusted with static rt rights, s/he is not to be trusted with any
kind of rt rights, no matter how clever the daemon that grants them. so
what is the problem you are trying to solve?

this is really akin to handing out root rights and watching the
filesystem, and as soon as the user starts reading other people's mail
some script yells at him.

[Lennart Poettering]

Post by Jörn Nettingsmeier

Post by Lennart Poettering
What is so difficult to understand that rtkit is not intended to be a
solution for hardcore rt users?
rtkit is not for you!
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.

The worst thing that can happen is that we demote more processes than
necessary. But so what? As long as the evildoer's process is
demoted/killed you have a usable system again.

Also, stuff such as RLIMIT_RTTIME (which we specifically check to be
set in clients in rtkit) should make sure that the process cannot even
misuse RT in the first place.

Really, all this has been answered before. You can run around in
circles if you like to, but this is where I get off.

Lennart

[Jörn Nettingsmeier]

Post by Lennart Poettering

Post by Jörn Nettingsmeier

Post by Lennart Poettering
What is so difficult to understand that rtkit is not intended to be a
solution for hardcore rt users?
rtkit is not for you!
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?

[drew Roberts]

Post by Lennart Poettering
The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around.

I am one of those who also haven't read the README. I have been trying to
follow this thread with a bit more than non-interested care though.

Post by Lennart Poettering
rtkit is a just missing piece of the puzzle that allows distros to
enable RT by default for their desktop users.

Here is a small bit of an attempt at being constructive.

I don't think I saw any assertion in the thread as to the benefits of enabling
RT by default for all desktop users? (I may have missed it or forgotten it
though) What is gained by this? What are normal desktop users doing than
needs RT? (I am asking out of a large pool of ignorance here but I have a
feeling from the thread that people may not be seeing the benefit of
this...???)

all the best,

drew

[Lennart Poettering]

Post by drew Roberts
Here is a small bit of an attempt at being constructive.
I don't think I saw any assertion in the thread as to the benefits of enabling
RT by default for all desktop users? (I may have missed it or forgotten it
though) What is gained by this? What are normal desktop users doing than
needs RT? (I am asking out of a large pool of ignorance here but I have a
feeling from the thread that people may not be seeing the benefit of
this...???)

Has been answered before. I want to make PA RT by default. PA is
installed default on all big distros.

Lennart

[Fernando Lopez-Lezcano]

Post by drew Roberts

Post by Lennart Poettering
The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around.

I am one of those who also haven't read the README. I have been trying to
follow this thread with a bit more than non-interested care though.

Post by Lennart Poettering
rtkit is a just missing piece of the puzzle that allows distros to
enable RT by default for their desktop users.

Here is a small bit of an attempt at being constructive.
I don't think I saw any assertion in the thread as to the benefits of enabling
RT by default for all desktop users? (I may have missed it or forgotten it
though) What is gained by this? What are normal desktop users doing than
needs RT? (I am asking out of a large pool of ignorance here but I have a
feeling from the thread that people may not be seeing the benefit of
this...???)

Basically playing sound. So that playback does not skip and can have
reasonable latencies. If the process that is playing sound gets
preempted out because of the workload of the machine and can't feed the
sound card soon enough you get a click. Humans are very sensitive to
that (more than to, say, a missed frame in video playback).

-- Fernando

[Dennis Schulmeister]

Hi,

Post by Fernando Lopez-Lezcano

Post by drew Roberts
I don't think I saw any assertion in the thread as to the benefits of enabling
RT by default for all desktop users? (I may have missed it or forgotten it
though) What is gained by this? What are normal desktop users doing than
needs RT? (I am asking out of a large pool of ignorance here but I have a
feeling from the thread that people may not be seeing the benefit of
this...???)

Basically playing sound. So that playback does not skip and can have
reasonable latencies. If the process that is playing sound gets
preempted out because of the workload of the machine and can't feed the
sound card soon enough you get a click. Humans are very sensitive to
that (more than to, say, a missed frame in video playback).

Then the assumption is that an audio-playing process belongs to the
top-priority processes which deserve the most computation time (on a
typical desktop system). I wouldn't agree to that assumption. Sure I do
have a media player running in the background and I don't want the
playback to click or skip. The same goes for video watching and so on.
But I might accept drop outs if the machine is under heavy load (like
when compiling a large program, rendering a video, ...) and don't want
the media player to consume all the computation power.

But then latency is no issue either as a media player most often plays
static files which can be read in advance to keep the buffers full. The
same goes for web streams which need to be buffered anyway in order to
compensate jitter and limited bandwidth. Typically between 1/3 and 1/5
second is responsive enough for most desktop applications and still
makes for plenty audio buffers even under non-rt situations.

So after reading all those messages I'm somewhat left up wondering if
the addressed problem (real-time audio for desktop applications) really
is an existing problem. The same goes for the theoretical threat of a
rt-fork bomb. Just because in theory someone could write such a program
and make it run on a someone else's machine doesn't seem like enough
reasoning for implementing a protection mechanism on a large user base.
In theory there are much more real threats for the average user which
nobody cared to address. And it has been shown that in theory the
suggested protection mechanism can be circumvented, too.


BTW: I read the README file and don't see why it should be required
reading for this thread. Lennart explained it much better through his
mails than the README file (which contains two typos :-).



Yours sincerely,
Dennis Schulmeister

PS: Sorry Fernando for first sending this directly to you.

[Lennart Poettering]

Post by Dennis Schulmeister
So after reading all those messages I'm somewhat left up wondering if
the addressed problem (real-time audio for desktop applications) really
is an existing problem. The same goes for the theoretical threat of a
rt-fork bomb. Just because in theory someone could write such a program
and make it run on a someone else's machine doesn't seem like enough
reasoning for implementing a protection mechanism on a large user base.
In theory there are much more real threats for the average user which
nobody cared to address. And it has been shown that in theory the
suggested protection mechanism can be circumvented, too.

Take it from a desktop developer: it does make a difference if PA is
RT or not.

And there are no plans to make every media player RT. Nobody is
suggesting that.

Lennart

[Dennis Schulmeister]

Post by Lennart Poettering
Take it from a desktop developer: it does make a difference if PA is
RT or not.

I'd be curious which difference it makes.

Post by Lennart Poettering
And there are no plans to make every media player RT. Nobody is
suggesting that.

Okay, that was inaccurate by me. But still audio performance has always
been fine for typical desktop usage without rt privileges me thinks.
Because the issue of latency is relative in that case. But maybe I'm
missing an important point.



Yours sincerely,
Dennis Schulmeister

[Esben Stien]

audio performance has always been fine for typical desktop usage
without rt privileges me thinks. Because the issue of latency is
relative in that case. But maybe I'm missing an important point.

Sure, like VoIP.

[Fernando Lopez-Lezcano]

Post by Esben Stien

audio performance has always been fine for typical desktop usage
without rt privileges me thinks. Because the issue of latency is
relative in that case. But maybe I'm missing an important point.

Sure, like VoIP.

& games...
-- Fernando

[Dennis Schulmeister]

Post by Esben Stien

audio performance has always been fine for typical desktop usage
without rt privileges me thinks. Because the issue of latency is
relative in that case. But maybe I'm missing an important point.

Sure, like VoIP.

There's the buffer argument again. Even a highly compressed
low-bandwidth VoIP stream needs to be buffered by the application
because of the annoying factor not being latency but jitter. If you do a
"regular" phone call from one mobile phone to another you easily get 1
second latency. The point is you don't notice it unless you're standing
next to the other person.

But then what's the reason behind ultra-small hardware buffers which
need to be refreshed very quickly in contrast to the comparatively large
buffers needed for the input stream in the first place?

I see the reasoning for games, though.



Yours sincerely,
Dennis Schulmeister

[Stefan Kost]

Post by Dennis Schulmeister
Hi,

Post by Fernando Lopez-Lezcano

Post by drew Roberts
I don't think I saw any assertion in the thread as to the benefits of enabling
RT by default for all desktop users? (I may have missed it or forgotten it
though) What is gained by this? What are normal desktop users doing than
needs RT? (I am asking out of a large pool of ignorance here but I have a
feeling from the thread that people may not be seeing the benefit of
this...???)

Basically playing sound. So that playback does not skip and can have
reasonable latencies. If the process that is playing sound gets
preempted out because of the workload of the machine and can't feed the
sound card soon enough you get a click. Humans are very sensitive to
that (more than to, say, a missed frame in video playback).

Then the assumption is that an audio-playing process belongs to the
top-priority processes which deserve the most computation time (on a
typical desktop system). I wouldn't agree to that assumption. Sure I do
have a media player running in the background and I don't want the
playback to click or skip. The same goes for video watching and so on.
But I might accept drop outs if the machine is under heavy load (like
when compiling a large program, rendering a video, ...) and don't want
the media player to consume all the computation power.

Just a small comment. Its not about computation time so much, its about
regular scheduling.

Post by Dennis Schulmeister
But then latency is no issue either as a media player most often plays
static files which can be read in advance to keep the buffers full. The
same goes for web streams which need to be buffered anyway in order to
compensate jitter and limited bandwidth. Typically between 1/3 and 1/5
second is responsive enough for most desktop applications and still
makes for plenty audio buffers even under non-rt situations.

Even if its for memory reasons, media players don't read even static
files totally in advance. media is rendered in chunks. of course its a
good idea to do some extra buffering in non-interactive playback case
where latency does not matter so much.

I'd say most users would prefer if the media playback can ensure smooth
playback.

Stefan

Post by Dennis Schulmeister
So after reading all those messages I'm somewhat left up wondering if
the addressed problem (real-time audio for desktop applications) really
is an existing problem. The same goes for the theoretical threat of a
rt-fork bomb. Just because in theory someone could write such a program
and make it run on a someone else's machine doesn't seem like enough
reasoning for implementing a protection mechanism on a large user base.
In theory there are much more real threats for the average user which
nobody cared to address. And it has been shown that in theory the
suggested protection mechanism can be circumvented, too.
BTW: I read the README file and don't see why it should be required
reading for this thread. Lennart explained it much better through his
mails than the README file (which contains two typos :-).
Yours sincerely,
Dennis Schulmeister
PS: Sorry Fernando for first sending this directly to you.

[Fons Adriaensen]

Post by Lennart Poettering
It was clearly a bad idea to post about rtkit on lad. It is a big
waste of time fighting this through against all those desktop-haters,
fdo-haters, dbus-haters, who apparently believe I am out to take away
their freedom to run their systems the way want. I really don't need
this shit. The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around.

Reading it does not imply agreeing with everything
said there. If it makes your life easier: I *did*
read it.

Since you claim that all the *Kit stuff is optional,
and you will still allow us to run our systems as we
see fit, and since you wear a Red Hat, please tell
me how to remove

root 1830 1 0 Jun22 ? 00:00:00 /usr/sbin/console-kit-daemon

permanently in FC10. It used to be a service but
apparently isn't anymore. And while you're at it,
and since I don't run gdm or gnome, same for:

fons 2243 1 0 Jun22 ? 00:00:00 /usr/bin/gnome-keyring-daemon -d --login
fons 2309 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfsd
fons 2346 1 0 Jun22 ? 00:00:00 /usr/libexec//gvfs-fuse-daemon /home/fons/.gvfs
fons 2434 1 0 Jun22 ? 00:00:00 /usr/libexec/gconf-im-settings-daemon
fons 2436 1 0 Jun22 ? 00:00:00 /usr/libexec/gconfd-2
fons 2516 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfs-hal-volume-monitor
fons 2518 1 0 Jun22 ? 00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor

Once that is taken care of, I may start to believe what
you say.

Ciao,

[Lennart Poettering]

Post by Fons Adriaensen

Post by Lennart Poettering
It was clearly a bad idea to post about rtkit on lad. It is a big
waste of time fighting this through against all those desktop-haters,
fdo-haters, dbus-haters, who apparently believe I am out to take away
their freedom to run their systems the way want. I really don't need
this shit. The amount of constructive criticism in this thread is next
to zero, nobody even bothers to read the README before just fudding
around.

Reading it does not imply agreeing with everything
said there. If it makes your life easier: I *did*
read it.
Since you claim that all the *Kit stuff is optional,

(as a side note, I didn't claim that)

Post by Fons Adriaensen
and you will still allow us to run our systems as we
see fit, and since you wear a Red Hat, please tell
me how to remove

Just downgrade to FC5 or so. Or pick a different distro that is
suited more to your needs.

Nobody forced you to use Fedora. If you are unhappy with the decisions
Fedora took, then you are welcome to change distros or take the code
you like and create your own distro.

You are a troll, and this is wildly off-topic, and I am not a support
guy, so please drop this nonsense.

Lennart

[Fons Adriaensen]

Post by Lennart Poettering
Just downgrade to FC5 or so. Or pick a different distro that is
suited more to your needs.

Actually F8 would be enough. ConsoleKit was a service there and I
just disabled it without any ill effect.

In F10 that choice has been removed, and I predict that
whatever you wirte today, the same will happen with your
RealtimeKit.

Today you claim it's optional, 'if it's not for you then don't
use it', etc. etc.

Maybe it will be optional in F12. But based on previous
experience I'm pretty sure things won't stay like that.

By the time we are at F13 or 14, if someone asks you how to
disable RealtimeKit, your answer will be similar to the one
you gave above: 'downgrade to F10 or use a distro that better
suits your needs, nobody is forcing you use Fedora, etc.'

Indeed, nobody is forcing me to use Fedora. But it is the
base of one of the best specialised audio distros, CCRMA.

Maybe you don't care about that, then just say so.


Ciao,

[Bob Ham]

Post by Lennart Poettering

Post by Fons Adriaensen
Since you claim that all the *Kit stuff is optional,

(as a side note, I didn't claim that)

Post by Fons Adriaensen
and you will still allow us to run our systems as we
see fit, and since you wear a Red Hat, please tell
me how to remove

Just downgrade to FC5 or so.

This response shows a real problem. The fact that you cannot disable
these kinds of services without forking shows there's a design problem.
The fact that these badly-designed services have become so widespread
shows a deeper problem.

Recently, money seems to have become quite influential in the free
software community, typified by Red Hat and its efforts to drive free
software development in a direction that suits enterprise customers.
The quoted response shows an unwillingness for these parties to
*cooperate* with communities and instead I see a desire to *dictate* to
communities.

Yes, I can fork Fedora and create a new distribution but that takes a
great deal of time and effort. If Red Hat were interested in
cooperating instead of dictating, that effort would not be needed; Red
Hat would take on the responsibility of ensuring that their systems are
flexible enough not to need a fork. Practically, that means designing
software systems in such a way as they can be easily disabled.


Being fuelled by money, this new influence in free software is
susceptible to the control of any parties willing to spend enough. That
opens the possibility of a fifth column within the free software
community. I've previously argued that in future, it may be necessary
to protect the interests of free software by forking away from this
influence if it starts behaving as a fifth column.

The above response shows that this influence is already having a
detrimental affect on the quality of free software. I wonder if it
won't be necessary to fork away from this influence, purely because of
the sub-standard nature of the solutions it produces.

RealtimeKit demonstrates this sub-standard nature in that it's a
workaround. It provides an API to be used if a system call fails. This
is not a problem in itself but there seems to be no desire to spend the
time and effort needed to deal with the issue of why the system call is
failing. Instead, there seems to be only a narrow-minded drive to
produce the next-best *Kit, which will provide an all-new service to
enable our enterprise customers!

It's great that all these new Kits are putting free software in the
hands of average users. What isn't great is that they seem to be
hastily developed and without concern for the wider free software
community. There will be consequences of this lack of concern.

Bob

[Bob Ham]

Post by Lennart Poettering
this offers an API of
two tiny functions.
And rtkit is just a tiny piece of software that only requires minimal
additions to client code to be useful.

Post by Adam Sampson
If
you want to make it easier for people to write realtime applications, I
think it'd be nicer -- and certainly more portable -- to provide a
librealtimethread

I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call.

There's something wrong here.

[Fons Adriaensen]

Post by Bob Ham
There's something wrong here.

There is a lot wrong here.


* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

* Why should an app running on an headless system at RL3 be forced
to go through a collection of desktop-oriented daemons in order to
do something that amounts to a simple POSIX system call ?

* Claiming that 'group based security is broken' is not only
a show of ignorance, but also of arrogance. All UNIX sysadmins
of the last 30 years must have been idiots.

* I don't run a 'desktop' on any machine, nor do I want one.
The thing I'm looking at is a computer screen, and that's it.
I want to remain the master of my system, whatever I do is
by definition to be trusted. This includes running RT threads
that may block the machine. I'm not married into the Kit
family, and the last thing I want is this collection of
mothers-in-law interfering with my system. If the the desktop
kids want this sort of thing that's fine. Let them build it
into their desktops, but keep it out of the operating system.

* All this talk from the freedesktop crowd about 'security'
is as misleading as it can be, *All* security violations
I've seeen lately on any of my systems were generated by
these desktop madness. This includes:

- Gdm making unauthorised network connections (disable
DNS and see it hang for two minutes).

- Login manangers changing device permissions.

- Gnome automounting removable disks that don't have
the 'user' flags set in /etc/fstab.

- Digital camera software making unauthorised copies
of pictures to the local hard disk.

And more. This is 'big brother' security - basically
it means: 'trust us, we want the best for you, and are
trying to make your life easy'.

* If this trend continues then within a year or two
there will some 'FilesystemKit' that requires the OK
from freedesktop.org each time you open a file. And
no doubt also a 'DecencyKit' checking the color of
your underwear.

* It is IHMO high time to start the development of a
kernel patch that removes all of this, and provides a
clean POSIX system to those who want it.

Ciao,

[Chris Cannam]

Post by Fons Adriaensen
* Why should an app running on an headless system at RL3 be forced
to go through a collection of desktop-oriented daemons in order to
do something that amounts to a simple POSIX system call ?

I do think this is a rather unfair objection. Clearly the whole idea
here is to make this mechanism work better in a "desktop" context.
Applications on your properly configured headless system shouldn't
need to use this method at all.


Chris

[Lennart Poettering]

Post by Fons Adriaensen

Post by Bob Ham
There's something wrong here.

There is a lot wrong here.
* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

Is that so?

It can do both. resetting all is the default.

Post by Fons Adriaensen
* Why should an app running on an headless system at RL3 be forced
to go through a collection of desktop-oriented daemons in order to
do something that amounts to a simple POSIX system call ?

It shouldn't.

Quoting myself from the announcement: "If you don't do RT development
or doing RT development only for embedded cases, ... then it doesn't
mean anything for you."

rtkit is only relevant for the desktop. end of story.

A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
again? This is getting so old. And stays so wrong. D-Bus is deeply
rooted in system now, even the init system speaks it now. Get over it
already.

Post by Fons Adriaensen
* Claiming that 'group based security is broken' is not only
a show of ignorance, but also of arrogance. All UNIX sysadmins
of the last 30 years must have been idiots.

Oh my. Just because someone mentions that UNIX has issues you don't
have to call him "ignorant" and "arrogant".

Also, it's not me who declared that UNIX groups are broken. That's a
fight others have sucessfully fought through the distros
already. PolicyKit entered all major distributions.

If you think that UNIX is the only true verity and think that pk is an
abomination then bring that up with the pk guys, not with me.

Post by Fons Adriaensen
* I don't run a 'desktop' on any machine, nor do I want one.
The thing I'm looking at is a computer screen, and that's it.
I want to remain the master of my system, whatever I do is
by definition to be trusted. This includes running RT threads
that may block the machine. I'm not married into the Kit
family, and the last thing I want is this collection of
mothers-in-law interfering with my system. If the the desktop
kids want this sort of thing that's fine. Let them build it
into their desktops, but keep it out of the operating system.

Then don't do it. You are clearly not the intended audience of rtkit
then.

Have you actually read my announcement mail? This stuff is only useful
for out-of-the-box RT support on major distributions. If you roll
everything your own, because that makes you happy, then ignore rtkit.

Also, rtkit is just an offer. No need to adopt it if you think it is
an abomination. But if you do care that your software performs well
out-of-the-box on newer distros then think about it. The API is there,
you just make use of it.

Post by Fons Adriaensen
* All this talk from the freedesktop crowd about 'security'
is as misleading as it can be, *All* security violations
I've seeen lately on any of my systems were generated by

Yes, we hate security. And it is our declared objective to make your
life miserable. Surprised?

Post by Fons Adriaensen
* If this trend continues then within a year or two
there will some 'FilesystemKit' that requires the OK
from freedesktop.org each time you open a file. And
no doubt also a 'DecencyKit' checking the color of
your underwear.

Didn't you know, it's world domination we are going for! We want to
control your computer and then you, muhahaha. And we take away your
freedoms. And creating a working desktop is just our cover for
this. Muahahahaah! Muahahahahaahahaaaa!

Post by Fons Adriaensen
* It is IHMO high time to start the development of a
kernel patch that removes all of this, and provides a
clean POSIX system to those who want it.

Yes, do it! Not sure what exactly you want to patch out. But please do
it!

Lennart

[Paul Davis]

Lennart, I am still trying to understand what the basic rationale is
here. 3 years ago, the kernel mailing discussed RT scheduling and
decided that RLIMIT_RTPRIO was the way to handle access to this
capability. That decision was made knowing that some user-space
infrastructure would be necessary to make it usable for most
end-users. So, 3 years on, that user space infrastructure hasn't been
created, and now your proposed solution is to provide a different
method of accessing RT scheduling. Are you arguing/suggesting that the
user-space infrastructure will never be created because of the
security issues? Are you suggesting that the original decision to
focus on RLIMIT_RTPRIO was a mistake that didn't take "the reality of
what mainstream distros will do" into account?

--p

[Lennart Poettering]

Post by Paul Davis
Lennart, I am still trying to understand what the basic rationale is
here. 3 years ago, the kernel mailing discussed RT scheduling and
decided that RLIMIT_RTPRIO was the way to handle access to this
capability. That decision was made knowing that some user-space
infrastructure would be necessary to make it usable for most
end-users. So, 3 years on, that user space infrastructure hasn't been
created, and now your proposed solution is to provide a different
method of accessing RT scheduling. Are you arguing/suggesting that the
user-space infrastructure will never be created because of the
security issues?

What exactly are you asking for as "user-space infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp.

I mean, rtkit is user-space infrastructure, so what are you asking for
that isn't covered by rtkit?

Post by Paul Davis
Are you suggesting that the original decision to focus on
RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
mainstream distros will do" into account?

Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind. While I think even then it sucks UI-wise, it certainly was good
enough and better than anything there was before.

However, as soon as we want to make RT available out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.

Lennart

[Paul Davis]

Post by Lennart Poettering
What exactly are you asking for as "user-space infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp.

Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
to the kernel. Even by Ingo :) And no, you don't need to be a member
of a group - limits.conf can grant access on a per-user basis.

What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
easily configurable by the user. Its still not clear to me how this
works in the case of RTKit either.

Post by Lennart Poettering

Post by Paul Davis
Are you suggesting that the original decision to focus on
RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
mainstream distros will do" into account?

Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind.

This just isn't true! We had an earlier solution that was working OK
for audio production purposes BUT the kernel folks and embedded linux
developers were not happy about it. RLIMIT_RTPRIO was the result of
some quite extensive and at times heated discussion about how to
replace the old mechanism (based on kernel "capabilities" which have
now mostly gone away) with something else that would work for everyone
that had a stake in the outcome.

Post by Lennart Poettering
However, as soon as we want to make RT available out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.

I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
arguing that because we (will likely) have an RT-sched reset-on-fork
flag, that its now safe to grant RT scheduling permission by default?
First of all, I would dispute that this makes it "safe" in the sense
you want it to. By this I mean that although theoretically a clone
bomb would be stoppable with a kill(2) call, practically speaking the
machine would be rendered unusable by a suitable clone bomb attack.
That is - without the very things that you say we can't provide right
now - watchdogs, resource reservation scheduling (not isochronous),
and more. Secondly, if this flag is all that is needed to make it safe
to grant RT scheduling by default, why is RTKit needed at all?
Finally, you seem to continue assuming that SCHED_RR is the only
scheduling class of interest, which is by no means settled among the
various communities that use RT scheduling.

[Lennart Poettering]

Post by Paul Davis

Post by Lennart Poettering
What exactly are you asking for as "user-space infrastructure"? Some
easy to reach UI that will allow you to make yourself a member of some
group? This is unlikely to happen. At least not from the desktop
camp.

Well, this is precisely what was imagined when RLIMIT_RTPRIO was added
to the kernel. Even by Ingo :) And no, you don't need to be a member
of a group - limits.conf can grant access on a per-user basis.
What I mean by infrastructure are tools to make RLIMIT_RTPRIO settings
easily configurable by the user. Its still not clear to me how this
works in the case of RTKit either.

This is really the wrong approach. And no other OS does it. Really, how
would you find it if you install Fedora and one of the questions
during installation is whether you want to bump RLIMIT_RTPRIO for your
user, or not? Which user understands what "realtime" means anyway? My
mom certainly doesn't.

Sometimes, there is a bit of disconnect between what kernel folks
think is a good idea and what userspace folks think is one. [Which
(hint hint!) is precisely the reason why plumbers conf is so important
as an attempt to bridge that gap!]

Post by Paul Davis

Post by Lennart Poettering

Post by Paul Davis
Are you suggesting that the original decision to focus on
RLIMIT_RTPRIO was a mistake that didn't take "the reality of what
mainstream distros will do" into account?

Yes. I guess you can say that. Although I wouldn't call it a
"mistake". RLIMIT_RTPRIO was added with audio production in
mind.

This just isn't true! We had an earlier solution that was working OK
for audio production purposes BUT the kernel folks and embedded linux
developers were not happy about it. RLIMIT_RTPRIO was the result of
some quite extensive and at times heated discussion about how to
replace the old mechanism (based on kernel "capabilities" which have
now mostly gone away) with something else that would work for everyone
that had a stake in the outcome.

Back then audio and embedded realtime folks had a stake in the
outcome. Desktop folks did not, but apparently were expected to add
the "simple" UI for that? I mean, complaining that I now mostly kept
lad out of the loop is not entirely fair if back then you kept desktop
folks out of the loop...

(As a side note: capabilities are still there and doing better than
ever.)

Post by Paul Davis

Post by Lennart Poettering
However, as soon as we want to make RT available out-of-the-box
RLIMIT_RTPRIO just doesn't cut it.

I'm sorry, I'm still not grasping the idea. Or maybe I am. You're
arguing that because we (will likely) have an RT-sched reset-on-fork
flag, that its now safe to grant RT scheduling permission by
default?

I am arguing that if you have that flag you can set it when handing out
rt sched to other processes in a supervised fashion and be sure that
the process cannot escape your supervision.

Post by Paul Davis
First of all, I would dispute that this makes it "safe" in the sense
you want it to. By this I mean that although theoretically a clone
bomb would be stoppable with a kill(2) call, practically speaking the
machine would be rendered unusable by a suitable clone bomb attack.
That is - without the very things that you say we can't provide right
now - watchdogs,

As mentioned rtkit implements a watchdog, too. A watchdog however is
an a-posteriori solution to the problem. I.e. when things already
wrong it can be used to fix things up again. rtkit otoh tries to focus
on a-priori solutions, making sure that users cannot misuse RT in the
first place.

Please, please with cream on top, read rtkit's README:

http://git.0pointer.de/?p=rtkit.git;a=blob;f=README

Starting at line 39 is the part about watchdogs.

It also roughly explains the problems with the various other
approaches that were tried before.

Post by Paul Davis
resource reservation scheduling (not isochronous),
and more. Secondly, if this flag is all that is needed to make it safe
to grant RT scheduling by default, why is RTKit needed at all?

Because it fixes the problem that is "escaping supervision". Without
the patch a process can easily escape supervision or at least play
race games with the supervisor. rtkit is the supervisor.

Post by Paul Davis
Finally, you seem to continue assuming that SCHED_RR is the only
scheduling class of interest, which is by no means settled among the
various communities that use RT scheduling.

I have now changed rtkit to make the policy configurable system
wide. I believe the sched policy should be a choice for the admin, not
the developer, as it controls fairness of different RT software to
each other.

And again, as I already offered: if someone offers a good real-world
case then we can make the sched policy controllable from the client
side, too, and even the RR qantum, if that's really needed.

However, unless anyone makes a good case how this matters for desktop
applicatios I'd like to start small.

Lennart

[Fons Adriaensen]

Post by Lennart Poettering

Post by Fons Adriaensen
In the latter case this
system is not only broken, but should be classified as malware.

Is that so?

If something supposedly 'only relevant for the desktop' (your words)
interferes with thing that are not related to the desktop, yes.

Post by Lennart Poettering

Post by Fons Adriaensen
* Why should an app running on an headless system at RL3 be forced
to go through a collection of desktop-oriented daemons in order to
do something that amounts to a simple POSIX system call ?

It shouldn't.

Then it shouldn't ever. A desktop is just another application.

Post by Lennart Poettering
A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
again?

If I write 'a collection of desktop-oriented daemons' then I mean
exactly that. You have confirmed many times that is what they are.

Post by Lennart Poettering
Oh my. Just because someone mentions that UNIX has issues you don't
have to call him "ignorant" and "arrogant".

There is a world of difference between saying that UNIX has issues
and saying that group based security is broken. You could as well
say that wheel based transport is broken,

Post by Lennart Poettering
PolicyKit entered all major distributions.

The only thing required for that it to ensure it becomes a
dependency for Gnome. This will work for anything you want
and it does not demonstrate or imply any qualities.

Post by Lennart Poettering
If you think that UNIX is the only true verity and think that pk is an
abomination then bring that up with the pk guys, not with me.

I didn't bring it up with you.

Post by Lennart Poettering
Have you actually read my announcement mail? This stuff is only useful
for out-of-the-box RT support on major distributions. If you roll
everything your own, because that makes you happy, then ignore rtkit.

I will ignore it, also as an author. Or tell me why a RT DSP library
(which may create RT threads) should depened on any desktop-oriented
daemons.

Post by Lennart Poettering
Yes, we hate security. And it is our declared objective to make your
life miserable. Surprised?

Do you have a sensible answer to the four example issues I raised ?

Post by Lennart Poettering
Didn't you know, it's world domination we are going for! We want to
control your computer and then you, muhahaha. And we take away your
freedoms. And creating a working desktop is just our cover for
this. Muahahahaah! Muahahahahaahahaaaa!

Your words. I'm not suggesting anything like such a conspiracy.
But history shows over and over again that those who want to impair
freedom will deny their intentions. So your denial is as irrelevant
as your attempt to make me say things I didn't say.


Ciao,

[Lennart Poettering]

Post by Fons Adriaensen

Post by Lennart Poettering
A "collection of desktop-oriented daemons"? Do I smell D-Bus fud
again?

If I write 'a collection of desktop-oriented daemons' then I mean
exactly that. You have confirmed many times that is what they are.

rtkit is just one little bus-activated service. Not sure where you see
a "collection of daemons".

Post by Fons Adriaensen

Post by Lennart Poettering
Oh my. Just because someone mentions that UNIX has issues you don't
have to call him "ignorant" and "arrogant".

There is a world of difference between saying that UNIX has issues
and saying that group based security is broken. You could as well
say that wheel based transport is broken,

But group-bases access *is* broken. I mean, I am sorry if that hurts
your feelings, but uh, it's just the way it is.

Post by Fons Adriaensen

Post by Lennart Poettering
PolicyKit entered all major distributions.

The only thing required for that it to ensure it becomes a
dependency for Gnome. This will work for anything you want
and it does not demonstrate or imply any qualities.

FUD, FUD. FUD. FUD. FUD. FUD. FUD. And FUD.

KDE adopted it too. And quite a few system daemons too.

Lennart

[Fons Adriaensen]

Post by Lennart Poettering
FUD, FUD. FUD. FUD. FUD. FUD. FUD. And FUD.

Sounds like our prime minister: "Communists ! Communists !
Communists !". His standard answer to all critics. Even
the Financial Times is communist.

Ciao,

[Krzysztof Foltman]

Post by Fons Adriaensen

Post by Lennart Poettering
Have you actually read my announcement mail? This stuff is only useful
for out-of-the-box RT support on major distributions. If you roll
everything your own, because that makes you happy, then ignore rtkit.

I will ignore it, also as an author. Or tell me why a RT DSP library
(which may create RT threads) should depened on any desktop-oriented
daemons.

You're not ignoring it, you're practically waging the war against it,
effectively trying to make life more miserable for the desktop users
(yes, like me for example). Why?

The existence of rtkit doesn't make it harder for you to assign RT
privileges to every process on the machine. However, it makes it
possible to prevent rogue processes from obtaining/abusing the RT
scheduling while letting user-approved processes to still use it. In
some contexts, asking the users to give up every single application a
dangerous permission just to let them run your application, is a bad
idea (it makes any other application in the system capable of locking up
the PC without the chance of preventing it).

Okay, it uses a commonly available message passing infrastructure
(D-Bus) instead of reinventing the wheel. So what? Is one way of sending
messages to other processes somehow bad because it's an Evil Baby-Eating
D-Bus? POSIX is Good, FreeDesktop is Evil, since when? What's the
reasoning behind THAT?

Krzysztof

[Fons Adriaensen]

Post by Krzysztof Foltman
You're not ignoring it, you're practically waging the war against it,

Ever seen a real war ?

Post by Krzysztof Foltman
The existence of rtkit doesn't make it harder for you to assign RT
privileges to every process on the machine. However, it makes it
possible to prevent rogue processes from obtaining/abusing the RT
scheduling while letting user-approved processes to still use it.

Which rogue processes ? What was the last time you've seen a
RT-bomb ? Why did you run it ?

And anyay this thing protects against nothing at all.

Ciao,

[Krzysztof Foltman]

Post by Fons Adriaensen

Post by Krzysztof Foltman
You're not ignoring it, you're practically waging the war against it,

Ever seen a real war ?

Your point being?

Post by Fons Adriaensen

Post by Krzysztof Foltman
The existence of rtkit doesn't make it harder for you to assign RT
privileges to every process on the machine. However, it makes it
possible to prevent rogue processes from obtaining/abusing the RT
scheduling while letting user-approved processes to still use it.

Which rogue processes ? What was the last time you've seen a
RT-bomb ? Why did you run it ?

"When was the last time you've seen a Microsoft Word virus? Why did you
open it?" was probably some Microsoft manager's thinking more than
decade ago.

With the increasing number of Linux-based systems sold to novice users,
you're sure nobody will ever use RT API to do something nasty?

Basically, Lennart pointed out a potential security hole and shown a way
to fix it. The fact that it's not abused yet (mostly due to lack of
popularity of RT kernels) doesn't mean it won't be abused ever.
Especially if things like pulseaudio and games will making use of RT
privileges.

Krzysztof

[Fernando Lopez-Lezcano]

Post by Krzysztof Foltman

Post by Fons Adriaensen

Post by Krzysztof Foltman
You're not ignoring it, you're practically waging the war against it,

Ever seen a real war ?

Your point being?

Post by Fons Adriaensen

Post by Krzysztof Foltman
The existence of rtkit doesn't make it harder for you to assign RT
privileges to every process on the machine. However, it makes it
possible to prevent rogue processes from obtaining/abusing the RT
scheduling while letting user-approved processes to still use it.

Which rogue processes ? What was the last time you've seen a
RT-bomb ? Why did you run it ?

"When was the last time you've seen a Microsoft Word virus? Why did you
open it?" was probably some Microsoft manager's thinking more than
decade ago.
With the increasing number of Linux-based systems sold to novice users,
you're sure nobody will ever use RT API to do something nasty?
Basically, Lennart pointed out a potential security hole and shown a way
to fix it. The fact that it's not abused yet (mostly due to lack of
popularity of RT kernels)

Just a detail, but the issue at hand has nothing to do with the
popularity of rt kernels (ie: kernels patched with the rt patch), but
with allowing non-root users access to schedulers other than
SCHED_OTHER. That can happen with all current kernels.

-- Fernando

Post by Krzysztof Foltman
doesn't mean it won't be abused ever.
Especially if things like pulseaudio and games will making use of RT
privileges.

[Fons Adriaensen]

Post by Krzysztof Foltman

Post by Fons Adriaensen

Post by Krzysztof Foltman
You're not ignoring it, you're practically waging the war against it,

Ever seen a real war ?

Your point being?

My point being that if you use that word you'd better know
what it means.

Post by Krzysztof Foltman
Basically, Lennart pointed out a potential security hole and shown a way
to fix it.

It fixes nothing at all. It just makes a system fail in a different way
which IMHO is not better but rather worse than the original one.

Ciao,

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Fons Adriaensen

Post by Bob Ham
There's something wrong here.

There is a lot wrong here.
* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

Is that so?
It can do both. resetting all is the default.

Good question.

Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

(I assume, for example, that it would not under any circumstances reset
the scheduler of the kernel interrupt processes in an rt patched
kernel!!)

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fons Adriaensen

Post by Bob Ham
There's something wrong here.

There is a lot wrong here.
* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

Is that so?
It can do both. resetting all is the default.

Good question.
Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Even if some folks seem to believe it, I am not replacing anything
existing, shoving down their throats something they didn't need
before. All I do is adding something new, that helps a few desktopish
cases and can be integrated into various applications very easily and
with only minimal impact on dependencies, and is only used as fallback
if nothing else is configured.

Really, I am doing my best to ease adoptions for those interested.

Post by Fernando Lopez-Lezcano
(I assume, for example, that it would not under any circumstances reset
the scheduler of the kernel interrupt processes in an rt patched
kernel!!)

By default it only ever looks at non-root processes.

Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fons Adriaensen

Post by Bob Ham
There's something wrong here.

There is a lot wrong here.
* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ? In the latter case this
system is not only broken, but should be classified as malware.

Is that so?
It can do both. resetting all is the default.

Good question.
Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Maybe I did not frame the question correctly: if the system has been
configured on purpose by the administrator to grant !SCHED_OTHER by
using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
did not grant privileges to?

Post by Lennart Poettering
Even if some folks seem to believe it, I am not replacing anything
existing, shoving down their throats something they didn't need
before. All I do is adding something new, that helps a few desktopish
cases and can be integrated into various applications very easily and
with only minimal impact on dependencies, and is only used as fallback
if nothing else is configured.

I understand that as well. If I may disagree, the long term implication
of rtkit is not just helping a few desktopish cases. It may be why it
was written. But if successful, it will be the only way a distribution
will grant !SCHED_OTHER out of the box, so it will affect anything that
wants to run !SCHED_OTHER out of the box in that distribution (say,
Fedora), including, for example, jack & friends. Thus my concerns and
questions.

(yes, I understand RLIMIT_RTPRIO will still be there, the system will
just not be configured out of the box to grant any access through that
mechanism).

Post by Lennart Poettering
Really, I am doing my best to ease adoptions for those interested.

Post by Fernando Lopez-Lezcano
(I assume, for example, that it would not under any circumstances reset
the scheduler of the kernel interrupt processes in an rt patched
kernel!!)

By default it only ever looks at non-root processes.

Thanks...

Post by Lennart Poettering
* Question: is the 'demoting' of RT-threads applied only to RT
threads granted by this daeomon, or does it apply to all, including
those created by processes running as root ?

Note the part about "including those created by processes running as

Post by Lennart Poettering
It can do both. resetting all is the default.

To my eyes "resetting all" would mean to _include_ processes running as
root, thus my remark.

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
Good question.
Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Maybe I did not frame the question correctly: if the system has been
configured on purpose by the administrator to grant !SCHED_OTHER by
using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
did not grant privileges to?

rtkit is bus activated. It's only active when it is used. The
distinction between demoting all and demoting only the 'known'
processes is hence mostly theoretical.

I picked "demoting all" as the default since it 'felt' more
secure. Dunno. If someone can offer me real-world case where this
distinction really matters, I am all ears. Otherwise I'd got for the
safe default for now.

Post by Fernando Lopez-Lezcano
(yes, I understand RLIMIT_RTPRIO will still be there, the system will
just not be configured out of the box to grant any access through that
mechanism).

For RLIMIT_RTPRIO nothing changes. It wasn't enabled by default in the
big distros and it wont be enabled in the future either.

Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
Good question.
Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Maybe I did not frame the question correctly: if the system has been
configured on purpose by the administrator to grant !SCHED_OTHER by
using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
did not grant privileges to?

rtkit is bus activated. It's only active when it is used. The
distinction between demoting all and demoting only the 'known'
processes is hence mostly theoretical.

No, it is absolutely practical.

Post by Lennart Poettering
I picked "demoting all" as the default since it 'felt' more
secure. Dunno.

Well, sorry but IMO "feeling" has nothing to do with security (I
understand what you are saying, but we cannot base policy decisions like
this one on feeling or beauty or other subjective qualities).

What is rtkit assuming with that behavior? That any non-root process
that it did not authorize is fair game for it to meddle with. That is an
incorrect assumption.

Post by Lennart Poettering
If someone can offer me real-world case where this
distinction really matters, I am all ears. Otherwise I'd got for the
safe default for now.

_One_ of the available mechanisms for granting !SCHED_OTHER thinks it is
the only mechanism and acts accordingly. That is wrong.

-- Fernando

[Fernando Lopez-Lezcano]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
Good question.
Why is it resetting all the default, even processes with rt privileges
not granted by RealtimeKit? Isn't rtkit supposed to be the only
authorized way to access schedulers other that SCHED_OTHER by non-root
users?

rtkit doesn't need to be the exclusive consumer of the kernel RT
interfaces. RLIMIT_RTPRIO is another supported mechanism that
continues to work.

Maybe I did not frame the question correctly: if the system has been
configured on purpose by the administrator to grant !SCHED_OTHER by
using RLIMIT_RTPRIO, why does rtkit have to mess with processes that it
did not grant privileges to?

rtkit is bus activated. It's only active when it is used. The
distinction between demoting all and demoting only the 'known'
processes is hence mostly theoretical.

No, it is absolutely practical.

Post by Lennart Poettering
I picked "demoting all" as the default since it 'felt' more
secure. Dunno.

What is rtkit assuming with that behavior? That any non-root process
that it did not authorize is fair game for it to meddle with. That is an
incorrect assumption.

I think I may be misunderstanding something.
Or I'm just SSSLLLLOOOOWWWW...

Post by Fernando Lopez-Lezcano
rtkit only comes into play as last resort when rt is cannot otherwise
be required (at least if developers follow my recommendations from the
README). If the supervised realtime sched that rtkit gives you isn't
good enough, then simply give your application unsupervised RT by
means of RLIMIT_RTPRIO or CAP_SYS_NICE or something suchlike.

If rtkit would demote all processes when triggered, regardless of whether
rtkit granted the privileges or not then I can't really bypass it, it is
always there defining policy.

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano
If rtkit would demote all processes when triggered, regardless of whether
rtkit granted the privileges or not then I can't really bypass it, it is
always there defining policy.

Except that rtkit wouldn't be started in the first place if the apps
get RT by some other means, since rtkit is only the last resort for them.

But really, if this is so important to you then we can certainly
change that.


Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
If rtkit would demote all processes when triggered, regardless of whether
rtkit granted the privileges or not then I can't really bypass it, it is
always there defining policy.

Except that rtkit wouldn't be started in the first place if the apps
get RT by some other means, since rtkit is only the last resort for them.

Sorry to be a pest, if only _one_ app requests through rtkit then all
bets are off until a logout/login sequence, right?

Post by Lennart Poettering
But really, if this is so important to you then we can certainly
change that.

I happen to think it is the wrong thing to do in general: you are
essentially forcing policy for something you don't have complete control
over, so that it may overlap or override with what other methods want.
It is probably going to create problems in the long run, but that is a
very non-scientific thing to say.

(BTW, I still have to try to figure out if jack support is possible -
don't know when I'm going to have time - jack bestows rt on threads that
the client programs use, but not through a fork)

-- Fernando

[Chris Cannam]

Post by Paul Davis
Finally, as Chris said -
many of us are writing apps that target multiple platforms

Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience. Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using. PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.


Chris

[Patrick Shirkey]

Post by Chris Cannam

Post by Paul Davis
Finally, as Chris said -
many of us are writing apps that target multiple platforms

Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience. Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using. PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.

As a point of interest and comparison that has very little to do with
this debate, I just noticed that pulseaudio *is* being used in the Palm Pre

http://opensource.palm.com/packages.html

While Jack and Portaudio are not.




--
Patrick Shirkey
Boost Hardware Ltd.

[alex stone]

On Tue, Jun 23, 2009 at 2:33 PM, Patrick

Post by Paul Davis
Finally, as Chris said -
many of us are writing apps that target multiple platforms
Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience. Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using. PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.
As a point of interest and comparison that has very little to do with this
debate,  I just noticed that pulseaudio *is* being used in the Palm Pre
http://opensource.palm.com/packages.html
While Jack and Portaudio are not.
--
Patrick Shirkey
Boost Hardware Ltd.
_______________________________________________
Linux-audio-dev mailing list
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Patrick, the point is well made.

The decision's already been taken, excluding the wider linuxaudio
community, and no amount of enthusiastic input here will make any
difference to Lennert's intent, or anyone else involved in this
project.

Seems we got the short straw. Again.

A real shame.

Alex

[Patrick Shirkey]

Post by alex stone
On Tue, Jun 23, 2009 at 2:33 PM, Patrick

Post by Paul Davis
Finally, as Chris said -
many of us are writing apps that target multiple platforms
Well, my comment (from the point of view of applications rather than
library development) was not so much about portability as simple
convenience. Regardless of which method is ultimately used to
establish proper audio scheduling, it would be nice to be able to
handle it through the same audio API as I am already using. PortAudio
and JACK APIs both contain some support for this, PulseAudio is the
odd one out for me.
As a point of interest and comparison that has very little to do with this
debate, I just noticed that pulseaudio *is* being used in the Palm Pre
http://opensource.palm.com/packages.html
While Jack and Portaudio are not.
--
Patrick Shirkey
Boost Hardware Ltd.
_______________________________________________
Linux-audio-dev mailing list
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Patrick, the point is well made.
The decision's already been taken, excluding the wider linuxaudio
community, and no amount of enthusiastic input here will make any
difference to Lennert's intent, or anyone else involved in this
project.

I wouldn't go that far. Lennart has proven to be open to our suggestions
in the past and is prepared to work with everyone round here on the
matter of desktop integration and to a degree system design.

IMO what is missing at the moment is a unified plan from the LAD
community for desktop integration that is compatible with the unified
plan from the freedesktop community et al.

What I see is that Lennart and the others who have worked on pulseaudio
have done such a good job at making the platform accessible to the
desktop community that it has now become the defacto standard for Linux
Audio.

This was certainly helped by the insistence (for good reasons) that JACK
is not designed for normal users or non realtime desktop apps and the
lack of effort contributed to tackling the inherent issues.

However we do have a problem now that needs to be sorted with
integrating pa and jack in a way that is easy for everyone to work with.

Clearly Lennart has found that PA needs to be able to handle realtime
usage cases and is attempting in his best way to deal with those
problems. However there is soooo much cross over here that it is
becoming a dictatorial situation for those of us who are not
intrinsically tied too the pulse audio system.

Hence it is in everyones best interests to make sure this issue is
resolved or else we will have another alsa vs oss situation on our hands
for the foreseeable future.

By itself that is not a problem as that is the beauty of open source,
but for the average user it is a real headache.






Patrick Shirkey
Boost Hardware Ltd

Post by alex stone
Seems we got the short straw. Again.
A real shame.
Alex

[Fernando Lopez-Lezcano]

Post by Lennart Poettering
Heya,
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.

What other distros are considering its use? (or will use it?, or use it
currently?)

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

So this is, at this point, kernel version dependent, right?
What happens if you run a 2.6.29.x kernel?

The question is relevant, I think, as the kernels that I use (Planet
CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
support is still far in the future).

Post by Lennart Poettering
You
can set that flag when entering SCHED_RR scheduling and this will then
make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand out
RT to a process we can be sure it won't "leak", and if we decide to
take it away again we can be sure we can do that without having to be
afraid of races around forking.

If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

Post by Lennart Poettering
rtkit enforces limits on the the number of threads/processes/users
that get RT sched. It also does rate limiting, and calls into
PolicyKit before handing out RT. Finally, as extra a-posteriori
protection it also includes a canary watchdog.

How are all those limits set up and/or configured?

-- Fernando

[Paul Davis]

On Sun, Jun 21, 2009 at 7:06 PM, Fernando

Post by Fernando Lopez-Lezcano
If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

that's correct. there is no fork involved in setting up RT threads
inside JACK and even less for its clients.

i don't believe that lennart's RTKit relies on this though. The idea
is that a priviledged service is asked to give RT scheduling to a
thread, but because of Ingo's patch, it can grant it knowing that any
forked children will not also have RT scheduling.

of course, the name of lennart's new feature doesn't make it entirely
clear whether or not "fork" is equivalent to its "real" linux
implementation: clone. if it were not, then you could create an "RT
thread bomb" instead of a "fork bomb". i only did a quick reading of
his patch and in the context of the patch its not clear whether it
applies to every instance of clone() (i.e. thread or task creation) or
just plain fork().

--p

[Fernando Lopez-Lezcano]

Post by Paul Davis
On Sun, Jun 21, 2009 at 7:06 PM, Fernando

Post by Fernando Lopez-Lezcano
If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

that's correct. there is no fork involved in setting up RT threads
inside JACK and even less for its clients.
i don't believe that lennart's RTKit relies on this though. The idea
is that a priviledged service is asked to give RT scheduling to a
thread, but because of Ingo's patch, it can grant it knowing that any
forked children will not also have RT scheduling.

Without reading code it sounds from the description of RealtimeKit that
it is designed to avoid exactly the kind of thing Jack does routinely,
that is to grant rt scheduling to threads that belong to other processes
(the Jack clients).

-- Fernando

Post by Paul Davis
of course, the name of lennart's new feature doesn't make it entirely
clear whether or not "fork" is equivalent to its "real" linux
implementation: clone. if it were not, then you could create an "RT
thread bomb" instead of a "fork bomb". i only did a quick reading of
his patch and in the context of the patch its not clear whether it
applies to every instance of clone() (i.e. thread or task creation) or
just plain fork().

[Lennart Poettering]

Post by Paul Davis
of course, the name of lennart's new feature doesn't make it entirely
clear whether or not "fork" is equivalent to its "real" linux
implementation: clone. if it were not, then you could create an "RT
thread bomb" instead of a "fork bomb". i only did a quick reading of
his patch and in the context of the patch its not clear whether it
applies to every instance of clone() (i.e. thread or task creation) or
just plain fork().

The distinction between a thread/clone() and a process/fork() bomb
doesn't really matter. What matters is that you can kill() processes
and make the whole issue go away in one step even if that process has
one gazillion threads and wants to create even more.

Lennart

[Paul Davis]

Post by Lennart Poettering
The distinction between a thread/clone() and a process/fork() bomb
doesn't really matter. What matters is that you can kill() processes
and make the whole issue go away in one step even if that process has
one gazillion threads and wants to create even more.

that was sort of my precisely my point. i only read your patch, i
didn't look at it in the context of the whole kernel. if indeed it
only applies to fork() and not to clone() calls that create threads
and not tasks, then its not really protecting against anything, is it?
however, from what i could see of the patch the no-inherit-RT property
belongs to the process, not a thread, and thus could not be reset by a
thread create call without wierd semantics.

so it appears to me that your patch still leaves the kernel open to a
thread-bomb ... am i wrong?

[Lennart Poettering]

Post by Paul Davis

Post by Lennart Poettering
The distinction between a thread/clone() and a process/fork() bomb
doesn't really matter. What matters is that you can kill() processes
and make the whole issue go away in one step even if that process has
one gazillion threads and wants to create even more.

that was sort of my precisely my point. i only read your patch, i
didn't look at it in the context of the whole kernel. if indeed it
only applies to fork() and not to clone() calls that create threads
and not tasks, then its not really protecting against anything, is it?
however, from what i could see of the patch the no-inherit-RT property
belongs to the process, not a thread, and thus could not be reset by a
thread create call without wierd semantics.
so it appears to me that your patch still leaves the kernel open to a
thread-bomb ... am i wrong?

What SCHED_RESET_ON_FORK fixes is that a process cannot fork() (as in
process) to evade the kill() of a supervisor process.

Without this flag you always have a race where the killer process
would have a hard time killing a process that is duplicating itself
exponentially.

What matter is that to put an end to the thread bomb process all we
need to do is one call to kill().

Lennart

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
Heya,
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.

What other distros are considering its use? (or will use it?, or use it
currently?)

This is a dep of PA now. Since all major distros adopted PA I'd be
surprised if they wouldn't adopt rtkit too. If things run like they
usually run then this will enter the other distros one cycle past F12.

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

So this is, at this point, kernel version dependent, right?
What happens if you run a 2.6.29.x kernel?

Nothing. Then the call into rtkit will simply fail. Since the rtkit
call is intended to be used as fallback only things will work as well
or badly as they did before rtkit was introduced.

Post by Fernando Lopez-Lezcano
The question is relevant, I think, as the kernels that I use (Planet
CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
support is still far in the future).

Dunno. I disagree. The primary objective for rtkit is to be able to
run media applications as RT by default, out-of-the-box. I doubt that
this feature matters for legacy distros/kernels.

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
can set that flag when entering SCHED_RR scheduling and this will
then make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
out RT to a process we can be sure it won't "leak", and if we
decide to take it away again we can be sure we can do that without
having to be afraid of races around forking.

If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

Dunno. All processes that want to have rt need to ask rtkit
themselves. (which is the only safe thing to do, only then we get the
credentials properly defined)

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
rtkit enforces limits on the the number of threads/processes/users
that get RT sched. It also does rate limiting, and calls into
PolicyKit before handing out RT. Finally, as extra a-posteriori
protection it also includes a canary watchdog.

How are all those limits set up and/or configured?

Right now you can edit the service startup file and pass them as
command line parameters. Just read the README I linked.

Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
So what does RealtimeKit do that previous solutions didn't do? rtkit
relies on a new kernel feature SCHED_RESET_ON_FORK that got recently
merged into Ingo's tree and will hence shortly appear in 2.6.31.

So this is, at this point, kernel version dependent, right?
What happens if you run a 2.6.29.x kernel?

Nothing. Then the call into rtkit will simply fail. Since the rtkit
call is intended to be used as fallback only things will work as well
or badly as they did before rtkit was introduced.

Post by Fernando Lopez-Lezcano
The question is relevant, I think, as the kernels that I use (Planet
CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
support is still far in the future).

Dunno. I disagree. The primary objective for rtkit is to be able to
run media applications as RT by default, out-of-the-box. I doubt that
this feature matters for legacy distros/kernels.

I'm talking about the rt kernels specifically. In that context users
don't have a real choice as to what they get to run and the meaning of
legacy is different (I understand you may not care because of the target
audience of PA, but then again the RealtimeKit is being proposed as a
generic solution for access to rt scheduling).

If the rt patch does not catch up fast enough then I may need to run a <
2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
is released, hardly a legacy distro :-)

(maybe unlikely, but it would not be the first time rt development
stalls for a looong time and you can't run the latest and greatest - not
complaining, just a fact)

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
can set that flag when entering SCHED_RR scheduling and this will
then make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
out RT to a process we can be sure it won't "leak", and if we
decide to take it away again we can be sure we can do that without
having to be afraid of races around forking.

If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

Dunno. All processes that want to have rt need to ask rtkit
themselves. (which is the only safe thing to do, only then we get the
credentials properly defined)

We should try to find out what happens in Jack's case.

It would be a __MAJOR__ step back if RealtimeKit is not usable by Jack
and it becomes the way distributions (and in particular Fedora) give
out-of-the-box access to rt scheduling.

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano
The question is relevant, I think, as the kernels that I use (Planet
CCRMA) are the rt patched kernels, currently limited to 2.6.29.5 (I
think Thomas and the rt gang are working on 2.6.30, I imagine 2.6.31
support is still far in the future).

Dunno. I disagree. The primary objective for rtkit is to be able to
run media applications as RT by default, out-of-the-box. I doubt that
this feature matters for legacy distros/kernels.

I'm talking about the rt kernels specifically. In that context users
don't have a real choice as to what they get to run and the meaning of
legacy is different (I understand you may not care because of the target
audience of PA, but then again the RealtimeKit is being proposed as a
generic solution for access to rt scheduling).
If the rt patch does not catch up fast enough then I may need to run a <
2.6.31 kernel (whatever is available at the time) in Fedora 12 when it
is released, hardly a legacy distro :-)
(maybe unlikely, but it would not be the first time rt development
stalls for a looong time and you can't run the latest and greatest - not
complaining, just a fact)

Again, the worst thing that happens is that you need to bump
RLIMIT_RTPRIO for your user, as you always did. rtkit doesn't take
that away.

Summary:

Kernel that lacks SCHED_RESET_ON_FORK: RLIMIT_RTPRIO is what matters.

Kernel that has SCHED_RESET_ON_FORK: RLIMIT_RTPRIO still matters when
it is set, rtkit is used as fallback.

Also note that supporting rtkit often enough doesn't add a build-time
dep to you application and the runtime dependency is very soft too: if
it isn't found it's not used, that's all.

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
can set that flag when entering SCHED_RR scheduling and this will
then make sure that after forking a child will be reset to
SCHED_OTHER. RT fork bombs can thus be made impossible: if we hand
out RT to a process we can be sure it won't "leak", and if we
decide to take it away again we can be sure we can do that without
having to be afraid of races around forking.

If I understand correctly then the mechanism would not be useful for
jack (leaving aside the issue of SCHED_RR vs. SCHED_FIFO), as jack
actually gives rt priority to threads in other processes (the clients of
jack). But maybe things have changed in the way jack works internally
these days, or, possibly I'm not completely understanding the
implications... hmmmmm... jack does not do any forking right?

Dunno. All processes that want to have rt need to ask rtkit
themselves. (which is the only safe thing to do, only then we get the
credentials properly defined)

We should try to find out what happens in Jack's case.

In JACK's sources the only place where I see fiddling with the
scheduler is in jack_acquire_real_time_scheduling(), which takes a
pthread_t. pthread_t is process local, so I am pretty sure JACK
doesn't try to change scheduling of out-of-process threads. This
should hence be perfectly compatible with the rtkit model.

Lennart

[Fernando Lopez-Lezcano]

Post by Lennart Poettering
Heya,
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
What's wrong with using RLIMIT_RPRIO?

You mean RLIMIT_RTPRIO?

Post by Lennart Poettering
The simple fact that we cannot
enable that by default since it basically empowers the user to freeze
the machine. Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

As to configuration file editing, I think that in properly configured
distributions /etc/security/limits.conf is set up out of the box (when a
package that needs the privileges is installed) so that it is
unnecessary to edit it manually.

-- Fernando

[Lennart Poettering]

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
Heya,
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default, and since it is now a dependency of
PulseAudio and things work how they work this will then not only be
available in Fedora 12 but also sooner or later in the other
distributions as well, installed by default.
What's wrong with using RLIMIT_RPRIO?

You mean RLIMIT_RTPRIO?

Yes.

Post by Fernando Lopez-Lezcano

Post by Lennart Poettering
The simple fact that we cannot
enable that by default since it basically empowers the user to freeze
the machine. Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

As to configuration file editing, I think that in properly configured
distributions /etc/security/limits.conf is set up out of the box (when a
package that needs the privileges is installed) so that it is
unnecessary to edit it manually.

Doing that is broken, and ugly.

Doing authorization via groups is broken, since practically you can
never take group membership away. Which is precisely one of the
reasons why PolicyKit got created.

Lennart

[Arnold Krille]

Post by Lennart Poettering
Doing authorization via groups is broken,

What??? Did you ever do administration for more then one computer???
Authorization by groups is _the only_ way to go if you have more then one user
to authorize for anything.
If you don't agree ask firms with intranets and net-wide authorization, look at
yp/nis/ldap/Active Directory.

Post by Lennart Poettering
since practically you can
never take group membership away.

Yes, you can. Just remove the person from a group and the next time the groups
are checked for that user, the rights are gone.

Arnold, still trying to understand why any distribution should now use
RealtimeKit after not really using rtlimits in PAM (except for the new run for
"Kits")

[Lennart Poettering]

Post by Arnold Krille

Post by Lennart Poettering
Doing authorization via groups is broken,

What??? Did you ever do administration for more then one computer???
Authorization by groups is _the only_ way to go if you have more then one user
to authorize for anything.
If you don't agree ask firms with intranets and net-wide authorization, look at
yp/nis/ldap/Active Directory.

Please read up on PoliyKit. What it does, and why it has been
introduced.

You practically cannot take group membership away from a user after
you gave it to him, and also adding a seperate group for every tiny
bit you need to authorize access to doesn't scale.

Post by Arnold Krille

Post by Lennart Poettering
since practically you can
never take group membership away.

Yes, you can. Just remove the person from a group and the next time the groups
are checked for that user, the rights are gone.

Except that this doesn't work.

http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html

Lennart

[Jens M Andreasen]

Since it is rogue processes - from the interweb? - rather than rough
users that are the potential problem, wouldn't the cure then be to grant
certain trusted applications RT-privileges?

A novice user would install well-known binaries from the distros
repository. The binary runs as user 'rt-audio' which is the only/one of
the few users on the system granted rt privileges.

jackd would be a single instance for all.

/j

[Lennart Poettering]

Post by Jens M Andreasen
Since it is rogue processes - from the interweb? - rather than rough
users that are the potential problem, wouldn't the cure then be to grant
certain trusted applications RT-privileges?
A novice user would install well-known binaries from the distros
repository. The binary runs as user 'rt-audio' which is the only/one of
the few users on the system granted rt privileges.

But uh, that app could then not access the starting user's file in any
way.

There is no such thing a trusted user applications. And I don't think
we want to go down the road to sandboxing for this.

Lennart

[Jens M Andreasen]

Post by Lennart Poettering
But uh, that app could then not access the starting user's file in any
way.

Of course it could! ... :-/

[Jörn Nettingsmeier]

Post by Lennart Poettering
You practically cannot take group membership away from a user after
you gave it to him, and also adding a seperate group for every tiny
bit you need to authorize access to doesn't scale.

security is a matter of good design, not of "oh, look, he has become
evil, let's revoke his privileges" ad-hockery.

it should never be necessary to automatically revoke rights from users.
if i have to get rid of a misbehaving creature fast, "passwd -l villain"
in combination with "mv ~villain/.ssh /tmp" and a quick pkill fixes
things for me. and the very good part is that this decision is made by a
human, not by some imperial shitload of policy that caters to the needs
of some mythical desktop user.

your rtkit cannot protect against anything, you can just play policy
catch-up with evildoers forever. that's about the same level of security
that outgoing firewalls in windows provide - you depend on process names
and whatnot, and if i rename "Internet Explorer.exe" to "Windows
Update.exe", i'm free to do as i please (not quite, but you get the idea).
this is *not security*. this is theater. proper security sometimes
includes the wisdom that certain threats cannot be met without throwing
out the child with the bathwater. some daemon fiddling with rt privs at
runtime in my book qualifies as drowning the child first, then throwing
it out. maybe eating it afterwards, but i'm not sure.

[Lennart Poettering]

Post by Jörn Nettingsmeier

Post by Lennart Poettering
You practically cannot take group membership away from a user after
you gave it to him, and also adding a seperate group for every tiny
bit you need to authorize access to doesn't scale.

security is a matter of good design, not of "oh, look, he has become
evil, let's revoke his privileges" ad-hockery.

Gah. You are so annoying.

rtkit includes the watchdog only as additional a-posteriori security
measure. The focus is clearly on a-priori security measures, i.e. not
handing out RT sched in a way that could be misused in the first place.

This is explicitly stressed in the README. Did you bother to read
that? No of course not.

Lennart

[Arnold Krille]

Post by Jörn Nettingsmeier
some daemon fiddling with rt privs at
runtime in my book qualifies as drowning the child first, then throwing
it out. maybe eating it afterwards, but i'm not sure.

Yippie! We are back at the "child eating" stage!

/me gets out the popcorn...

[nescivi]

Post by Jörn Nettingsmeier
your rtkit cannot protect against anything, you can just play policy
catch-up with evildoers forever. that's about the same level of security
that outgoing firewalls in windows provide - you depend on process names
and whatnot, and if i rename "Internet Explorer.exe" to "Windows
Update.exe", i'm free to do as i please (not quite, but you get the idea).
this is *not security*. this is theater.

Maybe that's where the confusion comes from!
In today's media and everyday life security is so often confused with theater,
and theater is so often used to make things seem secure, that we don't know
the difference anymore!
Ever been in an airport lately?

Only the bad actors get caught.

(which reminds me of that question on a certain well-known country's
immigration form, which asks whether or not I am planning to blow something
up, while I'm there. Like, I would answer yes if I did?).

Post by Jörn Nettingsmeier
proper security sometimes
includes the wisdom that certain threats cannot be met without throwing
out the child with the bathwater. some daemon fiddling with rt privs at
runtime in my book qualifies as drowning the child first, then throwing
it out. maybe eating it afterwards, but i'm not sure.

sincerely,
Marije

[Adam Sampson]

Post by Lennart Poettering
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default,

It would have been nice to see some mention of this on l-a-u/l-a-d
earlier (i.e. while it was being designed), since getting realtime
priority for audio applications is a problem that's been discussed and
experimented with many times in this community. I'd imagine that most
people reading this list are already using one of the existing solutions
to this problem, and thus may be less delighted than you'd expect to
have another mechanism dropped in their laps with no prior warning or
chance to feed into the design process. ;-)

I don't think it's a good idea to make the D-Bus interface the public
API for this, because it assumes that you *can* write a D-Bus service
that gives a thread in another process realtime priority (which is true
for Linux, but not obviously so for other systems, even free ones). If
you want to make it easier for people to write realtime applications, I
think it'd be nicer -- and certainly more portable -- to provide a
librealtimethread, which could try to call your D-Bus service if it's
available, and otherwise fall back to the existing well-tested
approaches for various platforms (e.g. by generalising the code from
jackd).

You appear to be heading this way with your example client code in rtkit
anyway -- but please don't tell people to "copy these sources into your
repository", particularly when they contain such blatantly unportable
constructs as "#ifdef __linux__"! What it actually cares about is
whether the D-Bus client library is available, which'd be easy enough to
have a configure script test for.

You also need to be careful about licensing. The license status of D-Bus
-- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are
dual-licensed under the Academic Free License 2.1 and the GNU GPL v2
(only). rtkit-test.c claims to be GPL v3 or later, which isn't possible,
since neither the AFL 2.1 or the GPL v2-only are compatible with that
according to the FSF <http://www.gnu.org/licenses/license-list.html>.
The best solution would be for the D-Bus folks to relicense their
client library under a more sensible permissive license...

(Incidentally, why the "-Kit" naming? There seem to be a few packages
like that around now, mostly providing a D-Bus service of some kind.)

Thanks,

[Lennart Poettering]

Post by Adam Sampson
I don't think it's a good idea to make the D-Bus interface the public
API for this, because it assumes that you *can* write a D-Bus service
that gives a thread in another process realtime priority (which is true
for Linux, but not obviously so for other systems, even free ones). If
you want to make it easier for people to write realtime applications, I
think it'd be nicer -- and certainly more portable -- to provide a
librealtimethread, which could try to call your D-Bus service if it's
available, and otherwise fall back to the existing well-tested
approaches for various platforms (e.g. by generalising the code from
jackd).

I am Linux developer. My priority is Linux.

rtkit is Linux-specific, internally it makes use of quite a few
Linux-only features. Which makes it very small and lean. I like it
that way.

Post by Adam Sampson
You appear to be heading this way with your example client code in rtkit
anyway -- but please don't tell people to "copy these sources into your
repository", particularly when they contain such blatantly unportable
constructs as "#ifdef __linux__"! What it actually cares about is
whether the D-Bus client library is available, which'd be easy enough to
have a configure script test for.

I guess one can't have one's cake and eat it too.

I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software. D-Bus otoh is nowadays so deeply integrated into th system
(heck, we now have it in the init system itself, too, and there
has been work to add kernel code for socket(AF_DBUS)), that it's
available everywhere and on many projects a dep anyway.

Also, the reference client should compile fine on non-Linux, however
it will become a NOP and return ENOSUPP when you call it. I added this
precisely to allow compilation of the code on other OSes and
minimizing the ifdef orgies.

Post by Adam Sampson
You also need to be careful about licensing. The license status of D-Bus
-- at least, as of 1.2.14 -- is a mess: the daemon and libdbus-1 are
dual-licensed under the Academic Free License 2.1 and the GNU GPL v2
(only).

Uh? To me it looks as if dbus was AFL/GPL2+ which a verified with a quick
grep over dbus' git repo.

How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?

Post by Adam Sampson
rtkit-test.c claims to be GPL v3 or later, which isn't possible,
since neither the AFL 2.1 or the GPL v2-only are compatible with that
according to the FSF <http://www.gnu.org/licenses/license-list.html>.
The best solution would be for the D-Bus folks to relicense their
client library under a more sensible permissive license...

dbus is GPL2+. When linked against the rkit daemon that gets
practically upgraded to GPL3. Problem solved.

Post by Adam Sampson
(Incidentally, why the "-Kit" naming? There seem to be a few packages
like that around now, mostly providing a D-Bus service of some kind.)

Hehe, it's all davidz's fault.

Lennart

[Adam Sampson]

Post by Lennart Poettering
I am Linux developer. My priority is Linux.

That's nice, but most of us developers don't have the luxury of being
able to forget about portability. I've spent quite a bit of effort
packaging software for other free operating systems, and there's already
a widespread (and largely justified) stereotype that Linux developers
don't write portable code. Please don't contribute to the problem.

Post by Lennart Poettering
I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software.

But instead you're proposing adding two dependencies (the D-Bus client
library and the RealtimeKit service), and having everybody who wants to
use it copy a large chunk of code into their project. I don't see how
that's a simpler option than providing a library interface; it's
certainly not simpler to write a configure test for.

Post by Lennart Poettering
Also, the reference client should compile fine on non-Linux, however
it will become a NOP and return ENOSUPP when you call it.

Whether the kernel is Linux or not is completely irrelevant for a
program trying to get realtime priority using your service. What matters
is whether D-Bus is available. Suppose I go away and implement your
realtime service for FreeBSD; because of that #ifdef, I now need to go
and patch every application that's copied your code before it'll work.

If the API were a library, like essentially every other API on a modern
Unix-like system, then I'd only have to change the library to add
support for new platforms and mechanisms, and I'd be able to support
systems where asking another process to increase your privileges isn't
the right way to do things.

Post by Lennart Poettering
How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?

It's stated clearly in the COPYING file for D-Bus: "D-Bus is licensed to
you under your choice of the Academic Free License version 2.1, or the
GNU General Public License version 2." If that isn't their intent, it
needs fixing.

[Lennart Poettering]

Post by Adam Sampson

Post by Lennart Poettering
I am Linux developer. My priority is Linux.

That's nice, but most of us developers don't have the luxury of being
able to forget about portability. I've spent quite a bit of effort
packaging software for other free operating systems, and there's already
a widespread (and largely justified) stereotype that Linux developers
don't write portable code. Please don't contribute to the problem.

Really, I see not much value in supporting more than one kernel. That
just means reinventing the wheel over and over. If others care, fine
for them.

Post by Adam Sampson

Post by Lennart Poettering
I don't think it is worth creating a tiny mini library that I'd need
to maintain and everyone depend on for just one (or two) little
function call. Especially since this would be an extra dep to a lot of
software.

But instead you're proposing adding two dependencies (the D-Bus client
library and the RealtimeKit service), and having everybody who wants to
use it copy a large chunk of code into their project. I don't see how
that's a simpler option than providing a library interface; it's
certainly not simpler to write a configure test for.

This is bogus. There is no dependency on rtkit here. if during runtime
the rtkit service is found it is used. If it is not found it isn't
used. end of story.

There is not compile time dependency on rtkit and no runtime
dependency either.

If I had introduced my own little library everyone would have to link
to it. However this way they just have to depend on dbus, which is
something many applications link to any way. So this way there is many
cae no dependency added at all. And the build is certainly easier.

Also, the client reference implementation is tiny. it just wraps two
method calls. Trivial stuff.

Post by Adam Sampson

Post by Lennart Poettering
How did you come to the conclusion that dbus was AFL/GPL2-only? Can you
point me to where this is claimed?

It's stated clearly in the COPYING file for D-Bus: "D-Bus is licensed to
you under your choice of the Academic Free License version 2.1, or the
GNU General Public License version 2." If that isn't their intent, it
needs fixing.

Then file a bug.

The .c/.h files are pretty explicit. Ever single file one has the
GPLv2+ blurb in it.

Lennart

[Chris Cannam]

Post by Lennart Poettering
Also, the client reference implementation is tiny. it just wraps two
method calls. Trivial stuff.

You're referring here to the code at
http://git.0pointer.de/?p=rtkit.git;a=blob;f=rtkit.c ? That's not
trivial. I appreciate that it's not difficult to cut and paste, but
still it's a pretty substantial replacement for one system call.
Surprisingly so, to me, having read much of the discussion before
looking at the code.


Chris

[Adam Sampson]

Post by Lennart Poettering
Really, I see not much value in supporting more than one kernel.

I find this statement surprising, having found that testing on multiple
operating systems is an excellent way of finding subtle bugs in code.
(I assume you're just talking about RealtimeKit here and not PulseAudio
as a whole, since there are clear advantages to making that available to
as large a userbase as possible if you want it to be widely adopted...)

Post by Lennart Poettering
There is not compile time dependency on rtkit and no runtime
dependency either.

Yes, there is a runtime dependency on RealtimeKit -- else there would be
no point in having it in the first place! If I'm building an operating
system package for an application that wants realtime priority, then my
package has to have an explicit dependency on RealtimeKit as well as
D-Bus.

Post by Lennart Poettering
Also, the client reference implementation is tiny. it just wraps two
method calls. Trivial stuff.

It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
non-comment/blank lines of code. The entirety of thread.c in libjack
(which handles getting realtime priority on a variety of operating
systems, among other things) is less than two hundred. This should be in
a library, *not* copied-and-pasted into multiple places; that's a
maintenance nightmare waiting to happen.

I should be clearer here that I think the RealtimeKit approach is
actually pretty sensible on Linux, and I don't have any objections to
using D-Bus. I just think it's important to recognise that this approach
is not appropriate for all platforms, and providing a more conventional
library interface would be more convenient for programmers, more
portable, and generally better software engineering practice.

Post by Lennart Poettering
Then file a bug.

I have done. I wasn't aware that it *was* a bug until you commented on
it; I'm used to trusting packages' explicit statements in their
documentation about their licenses. (Looking at license statements in
headers is not sufficient; as in RealtimeKit, it's very common to have
different licenses applying to different files, or dependencies on
libraries which end up restricting the license of the overall package.)

Thanks,

[Lennart Poettering]

Post by Adam Sampson

Post by Lennart Poettering
There is not compile time dependency on rtkit and no runtime
dependency either.

Yes, there is a runtime dependency on RealtimeKit -- else there would be
no point in having it in the first place! If I'm building an operating
system package for an application that wants realtime priority, then my
package has to have an explicit dependency on RealtimeKit as well as
D-Bus.

No.

rtkit is just an option. If distros install it, then you can use
it. If they don't then don't. The reference client code will magically
start to work if rtkit is around. If it isn't then there's still
RLIMIT_RTPRIO.

Really, there is no dependency.

Post by Adam Sampson

Post by Lennart Poettering
Also, the client reference implementation is tiny. it just wraps two
method calls. Trivial stuff.

It's neither trivial nor tiny -- rtkit.c is a bit over a hundred
non-comment/blank lines of code. The entirety of thread.c in libjack
(which handles getting realtime priority on a variety of operating
systems, among other things) is less than two hundred. This should be in
a library, *not* copied-and-pasted into multiple places; that's a
maintenance nightmare waiting to happen.

The reference implementation is relatively verbose, because it is
... a reference implementation. You can implement the real-time method
invocation in one call to dbus_message_new_method_call() followed by
dbus_message_append_args(), followed by
dbus_connection_send_with_reply_and_block(). Done.

Post by Adam Sampson
I should be clearer here that I think the RealtimeKit approach is
actually pretty sensible on Linux, and I don't have any objections to
using D-Bus. I just think it's important to recognise that this approach
is not appropriate for all platforms, and providing a more conventional
library interface would be more convenient for programmers, more
portable, and generally better software engineering practice.

I guess we have to agree to disagree here then.

Lennart

[Fernando Lopez-Lezcano]

Post by Adam Sampson

Post by Lennart Poettering
I just moved into Fedora Rawhide a little daemon called "RealtimeKit"
which will be enabled by default,

It would have been nice to see some mention of this on l-a-u/l-a-d
earlier (i.e. while it was being designed), since getting realtime
priority for audio applications is a problem that's been discussed and
experimented with many times in this community. I'd imagine that most
people reading this list are already using one of the existing solutions
to this problem, and thus may be less delighted than you'd expect to
have another mechanism dropped in their laps with no prior warning or
chance to feed into the design process. ;-)

Count me in as being surprised.

I would imagine it would be natural to include the LAD community in such
a discussion. If not _all_ of LAD, then I would imagine I would at least
invite the Jack developers to participate. If not _all_ of them, then at
least a small subset (the main developers).

After all Jack users, developers, packagers, system administrators, etc,
have been dealing with this very same issue publicly for many many
years[*] and were part of previous discussions about this...

Oh well...
-- Fernando


[*] in my case since 2001 or so (when Planet CCRMA went public - but if
I remember correctly I was using realtime scheduling access methods for
non-root users at CCRMA even before that).

My memory is fuzzy, but I may have the dubious distinction of being the
first to add a way to access SCHED_FIFO to jackd as a non-root user
using capabilities, as I needed that for CCRMA (based on code in, I
think, muse - or was it some other program?). A very ugly hack that
hopefully has been purged from the jack source code a long time ago :-)

[Emanuel Rumpf]

Post by Lennart Poettering
Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

Why not just create a small script to handle editing + reloading of
limits.conf :

$ allow_realtime_for_group audio yes
Allowed RT scheduling for group audio

$ allow_realtime_for_group audio no
Disallowed RT scheduling for group audio

Things seem to work well with limits.conf set up.
No reason to change it AFAIS.

[Lennart Poettering]

Post by Emanuel Rumpf

Post by Lennart Poettering
Also, asking the user to edit /etc/security/limits.conf
is certainly not user-friendly. We want to enable RT scheduling for
media aplications out-of-the-box.

Why not just create a small script to handle editing + reloading of
$ allow_realtime_for_group audio yes
Allowed RT scheduling for group audio
$ allow_realtime_for_group audio no
Disallowed RT scheduling for group audio
Things seem to work well with limits.conf set up.
No reason to change it AFAIS.

Dude. Seriously.

As pointed out gazillions of times handing our RLIMIT_RTPRIO to
everyone is an invitation to freeze the machine. While that might not
be a problem on an audio workstation, it is a problem for the big
distributions.

Lennart

[Jonathan Woithe]

Post by Lennart Poettering
What I am saying is that the current system is too "binary": Either
you have RT sched and then for *everything*. Or you haven't, and then
you haven't got it for *anything*.

But isn't this more to do with the missing userspace support infrastructure
that numerous people have pointed to than RTPRIO itself? RTPRIO itself does
not imply this "all or nothing" restriction since it *can* be set on a
per-application basis (given appropriate support in userspace for doing so).

I also had a problem with the way PAM did the "all or nothing" approach and
so I wrote set_rlimits - which grants user-specified RT privileges via
RTPRIO on a user/group/program-specific basis. It's not perfect (one has to
start applications via set_rlimits - eg: "set_rlimits ardour") but it works
for me and didn't take all that long to write. Given this I'm sure others
could come up with a workable RTPRIO-based system which included a nice
user-friendly GUI configuration applet (and so forth) - set_rlimits is a
proof-of-concept in a way which shows that something like this can be done.

I mention this because from where I stand on the periphery it seems to me
that the major issues with RTPRIO could well have been solved if the
related userspace support infrastructure had been written.

Post by Lennart Poettering
For the desktop case you need something in between: RT that cannot be
misused, basically. Doing that securely is particularly hard ...

Almost anything involving elevated privileges can and will be abused in
time. That's why the action requires elevated privileges in the first
place.

Regards
jonathan

[Lennart Poettering]

Post by Jonathan Woithe

Post by Lennart Poettering
What I am saying is that the current system is too "binary": Either
you have RT sched and then for *everything*. Or you haven't, and then
you haven't got it for *anything*.

But isn't this more to do with the missing userspace support infrastructure
that numerous people have pointed to than RTPRIO itself? RTPRIO itself does
not imply this "all or nothing" restriction since it *can* be set on a
per-application basis (given appropriate support in userspace for doing so).

You are misunderstanding what I was saying: either a process is
SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
full RT powers, or no RT powers at all. Desktop media stuff doesn't
need the full RT powers.

Post by Jonathan Woithe
I also had a problem with the way PAM did the "all or nothing" approach and
so I wrote set_rlimits - which grants user-specified RT privileges via
RTPRIO on a user/group/program-specific basis. It's not perfect (one has to
start applications via set_rlimits - eg: "set_rlimits ardour") but it works
for me and didn't take all that long to write. Given this I'm sure others
could come up with a workable RTPRIO-based system which included a nice
user-friendly GUI configuration applet (and so forth) - set_rlimits is a
proof-of-concept in a way which shows that something like this can be done.
I mention this because from where I stand on the periphery it seems to me
that the major issues with RTPRIO could well have been solved if the
related userspace support infrastructure had been written.

Processes with rtprio can fork as much as they want. With ptrace or
LD_PRELOAD or a similar mechanism users can load whatever they want
into those processes. That's why RLIMIT_RPRIO is not safe, and not
even remotely so.

Post by Jonathan Woithe

Post by Lennart Poettering
For the desktop case you need something in between: RT that cannot be
misused, basically. Doing that securely is particularly hard ...

Almost anything involving elevated privileges can and will be abused in
time. That's why the action requires elevated privileges in the first
place.

Sure, but that's no reason not to at least try to make the system safe
for abuses.

Lennart

[Paul Davis]

Post by Lennart Poettering
You are misunderstanding what I was saying: either a process is
SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
full RT powers, or no RT powers at all. Desktop media stuff doesn't
need the full RT powers.

now i'm even more confused. there are two properties we seem to be
discussing. one is which scheduling class a thread is in. the other is
whether the process has RLIMIT_RTPRIO set. you're saying that RTKit
puts the thread into the/a RT scheduling class, whereas
limits.conf/PAM/set_rlimits gives it RLIMIT_RTPRIO. correct?

a few more questions now that i've read the README once (more to come):

1) do you have a plan for mlock/mlock_all ?

2) if a distro decides they want RTKit around, why not set
SCHED_RESET_ON_FORK for init, thus preventing a fork bomb ever, and
run the watchdog as part of the regular startup process? why start it
on demand? then allow any process to obtain SCHED_FIFO/RR, knowing
that its now "safe" ?

3) in your README you claim "If processes that have real-time
scheduling privileges enter a busy loop they can freeze the entire the
system." But this seems to ignore the existence of :
/proc/sys/kernel/{sched_rt_period_us,sched_rt_runtime_us} which i
understood as preventing this without any other kernel mechanisms? I
quote from: http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-group.txt

"These defaults were chosen so that a run-away realtime tasks will not
lock up the machine but leave a little time to recover it."

so now i'm even more puzzled about what problem you are attempting to solve ...

[Fernando Lopez-Lezcano]

Post by Paul Davis

Post by Lennart Poettering
You are misunderstanding what I was saying: either a process is
SCHED_RR/FIFO or it is not. That's a binary thing. Either you get the
full RT powers, or no RT powers at all. Desktop media stuff doesn't
need the full RT powers.

now i'm even more confused. there are two properties we seem to be
discussing. one is which scheduling class a thread is in. the other is
whether the process has RLIMIT_RTPRIO set. you're saying that RTKit
puts the thread into the/a RT scheduling class, whereas
limits.conf/PAM/set_rlimits gives it RLIMIT_RTPRIO. correct?

Not my understanding at this point. Both limits.conf/PAM/set_rlimits and
rtkit give SCHED_FIFO|SCHED_RR to the process. Rtkit only gives
SCHED_RR(FIFO?) if RLIMIT_RTPRIO is set when the request is made, and
also ||'s the request with the new (forget its name) kernel flag that
resets a process's child to SCHED_OTHER when it forks.

-- Fernando

Post by Paul Davis
1) do you have a plan for mlock/mlock_all ?
2) if a distro decides they want RTKit around, why not set
SCHED_RESET_ON_FORK for init, thus preventing a fork bomb ever, and
run the watchdog as part of the regular startup process? why start it
on demand? then allow any process to obtain SCHED_FIFO/RR, knowing
that its now "safe" ?
3) in your README you claim "If processes that have real-time
scheduling privileges enter a busy loop they can freeze the entire the
/proc/sys/kernel/{sched_rt_period_us,sched_rt_runtime_us} which i
understood as preventing this without any other kernel mechanisms? I
quote from: http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/scheduler/sched-rt-group.txt
"These defaults were chosen so that a run-away realtime tasks will not
lock up the machine but leave a little time to recover it."
so now i'm even more puzzled about what problem you are attempting to solve ...
_______________________________________________

[nescivi]

Hey guys,

let me just try and be constructive here...

as far as I understand, RLIMIT_RTPRIO was decided as a solution about three
years ago, but lacks a userspace interface.

[Jens M Andreasen]

Post by Lennart Poettering
If you don't do RT development or doing RT development only for
embedded cases, or if you are a [/*intended explicitives deleted*/]
then it doesn't mean anything for you.
However, if you are a desktop developer interested to get your stuff
working out-of-the-box on modern distributions then you should think
about calling into RealtimeKit ...

What are the other applications - except for PA - that needs "fixing"?

Is this a PA specific problem only? In which case it could probably be
solved less violently.