7:29 p.m.
Hi,
Can I suggest that we consider adding new desktop users on a fresh
install to pulse-rt by default? Or, put another way, does anyone think
this is a particularly bad idea to be doing?
Jon.
7:48 p.m.
On Sun, 05.10.08 20:29, Jon Masters (jonathan(a)jonmasters.org) wrote:
Hi,
Can I suggest that we consider adding new desktop users on a fresh
install to pulse-rt by default? Or, put another way, does anyone think
this is a particularly bad idea to be doing?
It's a security issue.
If you add a user to pulse-rt he basically got the power to block the
CPU indefinitely and thus freeze the machine.
Unfortunately on Linux we don't have anything in place that would
allow "safe" usage of realtime features. There have been steps in the
right direction (like real-time group scheduling, RLIMIT_RTTIME), but
that is still a royal PITA to use or trivial to circumvent.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:56 p.m.
On Mon, 6 Oct 2008 02:48:46 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Sun, 05.10.08 20:29, Jon Masters (jonathan(a)jonmasters.org) wrote:
> Hi,
>
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone
> think this is a particularly bad idea to be doing?
It's a security issue.
If you add a user to pulse-rt he basically got the power to block the
CPU indefinitely and thus freeze the machine.
Unfortunately on Linux we don't have anything in place that would
allow "safe" usage of realtime features. There have been steps in the
right direction (like real-time group scheduling, RLIMIT_RTTIME), but
that is still a royal PITA to use or trivial to circumvent.
yeah it's better to not need realtime, and just have a good enough
scheduler instead ;-)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
8:42 p.m.
On Sun, 05.10.08 17:56, Arjan van de Ven (arjan(a)infradead.org) wrote:
> If you add a user to pulse-rt he basically got the power to
block the
> CPU indefinitely and thus freeze the machine.
>
> Unfortunately on Linux we don't have anything in place that would
> allow "safe" usage of realtime features. There have been steps in the
> right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> that is still a royal PITA to use or trivial to circumvent.
yeah it's better to not need realtime, and just have a good enough
scheduler instead ;-)
I'd love to see something like SCHED_ISO implemented: i.e. where a
process could specify how much CPU time it needs and how often. Would
be ideal for everything that requires a fixed amount of CPU but not
the entire CPU all the time. Would be perfect for video playback,
audio stuff, animations, and everything else.
And that same information would be useful as a replacement for all the
different latency APIs we have on Linux -- if a process says it needs
a bit of CPU every 30th of a second to bring a new movie frame to the
screen then this same information can be used to let the CPU sleep in
some deep sleep state for the rest of the time.
SCHED_ISO wuldn't just solve the security issue. It would also be
immensly useful and a nice API on top.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:20 p.m.
On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
On Mon, 6 Oct 2008 02:48:46 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
> On Sun, 05.10.08 20:29, Jon Masters (jonathan(a)jonmasters.org) wrote:
>
> > Hi,
> >
> > Can I suggest that we consider adding new desktop users on a fresh
> > install to pulse-rt by default? Or, put another way, does anyone
> > think this is a particularly bad idea to be doing?
>
> It's a security issue.
It's not a security issue if you're on a single user desktop/laptop, and
therefore something that could be configured up during installation. One
idea I had was to suggest having install "profiles" available - I'd love
to have an anaconda option I can click that will:
* Add me to sudoers automatically (first thing I do on every Fedora/RHEL
system, and the most annoying thing missing from a standard install)
* Add me to various groups useful to desktop self-admin, etc.
* (Disable SELinux policy with a vengeance :P)
> Unfortunately on Linux we don't have anything in place that
would
> allow "safe" usage of realtime features.
That's not true. You already have PolicyKit support and even look to see
if you have a policy. So that authorization could just be setup in
advance for pulseaudio if it's running on a desktop system.
There have been steps in the
> right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> that is still a royal PITA to use or trivial to circumvent.
yeah it's better to not need realtime, and just have a good
enough
scheduler instead ;-)
I agree about the longer term.
Jon.
10:01 p.m.
On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
On Sun, 2008-10-05 at 17:56 -0700, Arjan van de Ven wrote:
> On Mon, 6 Oct 2008 02:48:46 +0200
> Lennart Poettering <mzerqung(a)0pointer.de> wrote:
>
> > On Sun, 05.10.08 20:29, Jon Masters (jonathan(a)jonmasters.org) wrote:
> >
> > > Hi,
> > >
> > > Can I suggest that we consider adding new desktop users on a fresh
> > > install to pulse-rt by default? Or, put another way, does anyone
> > > think this is a particularly bad idea to be doing?
> >
> > It's a security issue.
It's not a security issue if you're on a single user desktop/laptop, and
therefore something that could be configured up during installation. One
idea I had was to suggest having install "profiles" available - I'd love
to have an anaconda option I can click that will:
* Add me to sudoers automatically (first thing I do on every Fedora/RHEL
system, and the most annoying thing missing from a standard install)
* Add me to various groups useful to desktop self-admin, etc.
* (Disable SELinux policy with a vengeance :P)
> > Unfortunately on Linux we don't have anything in place that would
> > allow "safe" usage of realtime features.
That's not true. You already have PolicyKit support and even look to see
if you have a policy. So that authorization could just be setup in
advance for pulseaudio if it's running on a desktop system.
> There have been steps in the
> > right direction (like real-time group scheduling, RLIMIT_RTTIME), but
> > that is still a royal PITA to use or trivial to circumvent.
> yeah it's better to not need realtime, and just have a good enough
> scheduler instead ;-)
I agree about the longer term.
Jon.
I have been fighting to get realtime working for a while on my computer
I use for composition, the normal scheduler just does not cut it for
this. While I agree that in the long run fixing that is the solution,
in the sort term it would be nice not to leave these type of users out
on a limb, or looking at other distros that do it by default.
just my $0.02
11:12 a.m.
On Sun, 2008-10-05 at 22:20 -0400, Jon Masters wrote:
It's not a security issue if you're on a single user
desktop/laptop, and
therefore something that could be configured up during installation. One
idea I had was to suggest having install "profiles" available - I'd love
to have an anaconda option I can click that will:
* Add me to sudoers automatically (first thing I do on every Fedora/RHEL
system, and the most annoying thing missing from a standard install)
* Add me to various groups useful to desktop self-admin, etc.
* (Disable SELinux policy with a vengeance :P)
Most of these require a user already created, which would mean this
should go in Firstboot instead.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:46 p.m.
On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
Hi,
Can I suggest that we consider adding new desktop users on a fresh
install to pulse-rt by default? Or, put another way, does anyone think
this is a particularly bad idea to be doing?
Seems kind of pointless. If you're running low on CPU time, giving
pulseaudio priority will likely just result in client buffers running
dry anyway. Is there anything in place to take care of the priority
inversion problem? I know jackd/jacklib has some scheduling magic in
it...
9:18 p.m.
On Sun, 05.10.08 20:46, Callum Lerwick (seg(a)haxxed.com) wrote:
On Sun, 2008-10-05 at 20:29 -0400, Jon Masters wrote:
> Hi,
>
> Can I suggest that we consider adding new desktop users on a fresh
> install to pulse-rt by default? Or, put another way, does anyone think
> this is a particularly bad idea to be doing?
Seems kind of pointless. If you're running low on CPU time, giving
pulseaudio priority will likely just result in client buffers running
dry anyway. Is there anything in place to take care of the priority
inversion problem? I know jackd/jacklib has some scheduling magic in
it...
I am not sure you fully understand what real-time is about. It is not
about giving some process "priority". That's what nice levels are for.
Taking care of the "priority inversion problem"? There is no need for
anyone to work around that, since we have PTHREAD_PRIO_INHERIT which
PA has been using for quite a while (although we are mostly lock-less
now).
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:54 a.m.
On Sun, Oct 05, 2008 at 08:46:18PM -0500, Callum Lerwick wrote:
pulseaudio priority will likely just result in client buffers
running
dry anyway. Is there anything in place to take care of the priority
inversion problem? I know jackd/jacklib has some scheduling magic in
it...
And on a lot of hardware the problem in the X server locking the bus up
anyway not the kernel scheduler. The intel driver developed that bad habit
between FC8 and FC9. Nothing the kernel can do if the PCI bus is being
hogged by another device so much the buffers drain.
Alan
5719
days inactive
5719
days old
9 comments
7 participants
participants (7)
-
Alan Cox -
Arjan van de Ven -
Brennan Ashton -
Callum Lerwick -
Jesse Keating -
Jon Masters -
Lennart Poettering