Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
22 Jun
2009
22 Jun
'09
7:44 p.m.
Lennart Poettering wrote:
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.
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
22 Jun
22 Jun
8:06 p.m.
New subject: [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
On Tue, 23.06.09 09:14, Jonathan Woithe (jwoithe(a)physics.adelaide.edu.au) wrote:
Sure, but that's no reason not to at least try to make the system safe
for abuses.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Lennart Poettering wrote:
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.
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.
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.
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. 
8:22 p.m.
New subject: [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
On Mon, Jun 22, 2009 at 8:05 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
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-grou…
"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 ...
8:49 p.m.
New subject: [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!
On Mon, 2009-06-22 at 20:22 -0400, Paul Davis wrote:
On Mon, Jun 22, 2009 at 8:05 PM, Lennart
Poettering<mzynq(a)0pointer.de> wrote:
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
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-grou…
"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 ...
_______________________________________________
8:48 p.m.
New subject: RLIMIT_RTPRIO userspace interface? (was: Re: [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!)
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.
From the post below, I understand that there is already
a small app made by
Jonathan Woithe that helps out in this aspect,
and that that could be expanded/adapted to do the job properly.
It seems that that would be a much more useful approach than adopting this
apparently controversial rtkit, which as I understand, also only works with
kernels newer than what anyone really has these days.
So it seems to me that if we put our thoughts together, figure out what we'd
want the userspace interface to be like for RLIMIT_RTPRIO, and get a few of us
to code this up, this would benefit a lot more people, as it would be
backwards compatible for kernels up to three years old. (That might be even a
previous Debian stable. :) ).
Plus, if I understand correctly, it wouldn't require changes to how things are
coded in audio programs, which would make it backwards compatible with all of
these cool apps, even the ones that are not so actively maintained anymore.
If we do this right, then it'll surely reach the main distros somehow :)
sincerely,
Marije
(who would just like to have easily configurable rt-stuff, with some readable
guides on how to do it properly).
On Monday 22 June 2009 19:44:01 Jonathan Woithe wrote:
Lennart Poettering wrote:
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.
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.
5426
days inactive
5426
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
5 participants
participants (5)
-
Fernando Lopez-Lezcano -
Jonathan Woithe -
Lennart Poettering -
nescivi -
Paul Davis