subject:"Re\: 2.6.11\-rc3\-mm2"

On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
> 
> > > > Yes. There's also the whole soft limit thing.
> > > 
> > > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > > jackd installed and runs it from X unprivileged, how does it get the
> > > elevated rlimit?
> > 
> > It needs a setuid launcher. It would be nice to be able to elevate the
> > rlimits of running processes but the API doesn't exist yet.
> 
> With a setuid launcher you need _zero_ kernel help to get SCHED_FIFO: if
> you have a launcher then already today it can just give SCHED_FIFO to
> jackd and be done with it!

I'm sure you know all this already but I'll spell it out so we're all
clear:

a) rlimits are tracked per-process so they're fundamentally
per-process
b) there are hard and soft limits, with soft always <= hard
c) only root can raise hard rlimits, but normal users can lower them
d) if a user owns a process, he can gain the privileges of that process
by various means, so in the strict sense per-process privileges are
meaningless - all privileges are per-uid
e) so we either need to segregate all privileged processes into
separate uid domains
f) or we're assuming non-malicious users and soft limits are
sufficient.

Now I suspect we don't want to insist people do (e) (though I'd
certainly encourage them to try).

Don't forget that the rlimits approach allows us to reserve the
highest priorities for root. I'm pretty sure an effective watchdog
policy can thus be implemented in userspace, which RT-LSM can't really
offer.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Lee Revell

On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote:
> On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> > >RT-LSM introduces architectural problems in the form of bogus API. And
> > 
> > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> > introduce *any* API whatsoever - it simply allows software to call
> > various existing APIs (mostly from POSIX) and have them not fail as
> > result of not being root and/or not running on a capabilities-enabled
> > kernel without the required caps.
> 
> The API is the parameters to modprobe or sysfs. 
> 

I think you are talking about the API for root to administer it vs. the
(lack of) API for apps to use the RT capabilities.  I think Paul's point
is that we can transparently replace it with something better (IMO the
RT rlimit is better) in the future, and the apps don't have to know
about it at all.  Comparing it to devfs/udev is bogus because those are
way, way more complicated.

> > >it's implemented as an LSM is meaningless if Redhat and SuSE ship it
> > >on by default.
> > 
> > We haven't encouraged anyone to ship anything with it on by default:
> > the idea is for the module to be present and usable, not turned on.
> 
> On as in turned on for build in the kernel config and shipped. But I
> expect people will eventually actually ship it _on_ with a group
> called 'rt' and possibly even put the primary user in there on install
> unless you start slapping some big fat warnings on it. (I just noticed
> the new Debian installer is putting the primary user in audio, cdrom,
> video, etc.)
> 

Sorry, if the distros are so dumb they need a big fat warning to know
that this is not a safe thing to enable by default, at least on anything
you would ever consider a multiuser system, then they get what they
deserve.  If they have half a brain they will use the setgid approach
that Ingo suggested, and only enable this for apps like JACK and
cdrecord that have been farily well audited and can be trusted to use
this feature (for example JACK has the internal watchdog to keep a bad
client from locking the system).  Really it only makes sense for a
distro to enable this if the user selects the "low latency desktop" or
"multimedia desktop" or whatever install option and makes clear that
this profile is NOT suitable for a multiuser system. 

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
> >RT-LSM introduces architectural problems in the form of bogus API. And
> 
> that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
> introduce *any* API whatsoever - it simply allows software to call
> various existing APIs (mostly from POSIX) and have them not fail as
> result of not being root and/or not running on a capabilities-enabled
> kernel without the required caps.

The API is the parameters to modprobe or sysfs. 

> >it's implemented as an LSM is meaningless if Redhat and SuSE ship it
> >on by default.
> 
> We haven't encouraged anyone to ship anything with it on by default:
> the idea is for the module to be present and usable, not turned on.

On as in turned on for build in the kernel config and shipped. But I
expect people will eventually actually ship it _on_ with a group
called 'rt' and possibly even put the primary user in there on install
unless you start slapping some big fat warnings on it. (I just noticed
the new Debian installer is putting the primary user in audio, cdrom,
video, etc.)

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 10:53:27AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
> 
> > On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> > > 
> > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> > > can be useful if you _need_ a scheduling guarantee due to physical
> > > constraints, and it can be useful if the hardware (or the kernel) cannot
> > > buffer enough, but otherwise, it only causes problems.
> > 
> > Agreed. I think something short of full SCHED_FIFO will make most
> > desktop folks happy. [...]
> 
> ah, but it's not the desktop folks who have to be happy but users :-)
> Really, if you ask any app designer then obviously 'the more CPU time we
> get for sure, the better our app behaves'. So in that sense SCHED_OTHER
> is a fair playground: if you behave nicely you'll have higher priority
> and shorter latencies.
> 
> (there are things like SCHED_ISO but how good of a solution they are is
> not yet clear.)
> 
> > [...] But a) we still have to figure out exactly how to do that and b)
> > we still have to make everyone else happy. The embedded folks (me
> > included) would prefer to not run our realtime bits as root too..
> 
> you dont have to - you can drop root after startup.
> 
> > > but i'm not sure how rlimits will contain the whole problem - can
> > > rlimits be restricted to a single app (jackd)?
> > 
> > Yes. There's also the whole soft limit thing.
> 
> i'm curious, how does this 'per-app' rlimit thing work? If a user has
> jackd installed and runs it from X unprivileged, how does it get the
> elevated rlimit?

It needs a setuid launcher. It would be nice to be able to elevate the
rlimits of running processes but the API doesn't exist yet.

>From the POV of accidental elevation to RT, soft limits are
sufficient. But we can't stop a user from exploiting an app they own
with RT privileges from elevating other apps via ptrace+exec or
whatever. Nor with RT-LSM.

> (while the rest of his desktop still runs with a safe
> rlimit.) SELinux/RT-LSM could do this, but i'm not sure about how
> rlimits give this to you.

How does it get done with RT-LSM? Setgid binaries? It only
discriminates on a group granularity. Or are you saying "and SELinux"
rather than "or SELinux"?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall <[EMAIL PROTECTED]> wrote:

> > > Yes. There's also the whole soft limit thing.
> > 
> > i'm curious, how does this 'per-app' rlimit thing work? If a user has
> > jackd installed and runs it from X unprivileged, how does it get the
> > elevated rlimit?
> 
> It needs a setuid launcher. It would be nice to be able to elevate the
> rlimits of running processes but the API doesn't exist yet.

With a setuid launcher you need _zero_ kernel help to get SCHED_FIFO: if
you have a launcher then already today it can just give SCHED_FIFO to
jackd and be done with it!

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Paul Davis

>introduced. See devfs. And I think the adoption barrier thing is a red
>herring as well: the current users are by and large compiling their
>own RT-tuned kernels.

not true. most people are using kernels built for specialized distros
or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic.

--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Yuval Tanny

In fs/Kconfig,
See "Documentation/filesystems/fscache.txt for more information." and 
"See Documentation/filesystems/cachefs.txt for more information."

Should be changed to:
"See Documentation/filesystems/caching/fscache.txt for more 
information." and "See Documentation/filesystems/caching/cachefs.txt for 
more information."

Thanks,
Yuval
Andrew Morton wrote:
cachefs-filesystem.patch
 CacheFS filesystem
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> > 
> > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> > can be useful if you _need_ a scheduling guarantee due to physical
> > constraints, and it can be useful if the hardware (or the kernel) cannot
> > buffer enough, but otherwise, it only causes problems.
> 
> Agreed. I think something short of full SCHED_FIFO will make most
> desktop folks happy. [...]

ah, but it's not the desktop folks who have to be happy but users :-)
Really, if you ask any app designer then obviously 'the more CPU time we
get for sure, the better our app behaves'. So in that sense SCHED_OTHER
is a fair playground: if you behave nicely you'll have higher priority
and shorter latencies.

(there are things like SCHED_ISO but how good of a solution they are is
not yet clear.)

> [...] But a) we still have to figure out exactly how to do that and b)
> we still have to make everyone else happy. The embedded folks (me
> included) would prefer to not run our realtime bits as root too..

you dont have to - you can drop root after startup.

> > but i'm not sure how rlimits will contain the whole problem - can
> > rlimits be restricted to a single app (jackd)?
> 
> Yes. There's also the whole soft limit thing.

i'm curious, how does this 'per-app' rlimit thing work? If a user has
jackd installed and runs it from X unprivileged, how does it get the
elevated rlimit? (while the rest of his desktop still runs with a safe
rlimit.) SELinux/RT-LSM could do this, but i'm not sure about how
rlimits give this to you.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
> 
> think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
> destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
> can be useful if you _need_ a scheduling guarantee due to physical
> constraints, and it can be useful if the hardware (or the kernel) cannot
> buffer enough, but otherwise, it only causes problems.

Agreed. I think something short of full SCHED_FIFO will make most
desktop folks happy. But a) we still have to figure out exactly how to
do that and b) we still have to make everyone else happy. The embedded
folks (me included) would prefer to not run our realtime bits as root
too..

> but i'm not sure how rlimits will contain the whole problem - can
> rlimits be restricted to a single app (jackd)?

Yes. There's also the whole soft limit thing.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 10:04:19AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
> 
> > So the comparison boils down to putting a magic gid in a sysfs
> > file/module parameter or setting an rlimit with standard tools (PAM,
> > etc). I'm really boggled that anyone could prefer the former,
> > especially since we had almost this exact debate over what became the
> > mlock rlimit!
> 
> the big difference to mlock is that for mlock there _is_ a _limit_. For
> RT scheduling the priority is _NOT_ a _limit_. Okay? So you give the
> false pretense of this being some kind of resource 'limit', while in
> fact allowing SCHED_FIFO prio 1 alone enables unprivileged users to lock
> up the system.
>
> so i could agree with RLIMIT_NICE (which _is_ a limit), but
> RLIMIT_RTPRIO sends the wrong message. The proper rlimit would be
> RLIMIT_RT_CPU (the patch i did).

It's not a perfect fit, I'll readily agree.

But consider this: with RLIMIT_RTPRIO, I can restrict a user to the
lowest N RT priorities. Then at N+1, I have an RT watchdog taking care
of runaways, tickled by a SCHED_NORMAL task. So it can still be looked
at as a meaningful limit, just a bit different from the others.

The RT LSM gives full CAP_SYS_NICE out, so there's no way to guarantee
that the watchdog has higher priority.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> So the comparison boils down to putting a magic gid in a sysfs
> file/module parameter or setting an rlimit with standard tools (PAM,
> etc). I'm really boggled that anyone could prefer the former,
> especially since we had almost this exact debate over what became the
> mlock rlimit!

the big difference to mlock is that for mlock there _is_ a _limit_. For
RT scheduling the priority is _NOT_ a _limit_. Okay? So you give the
false pretense of this being some kind of resource 'limit', while in
fact allowing SCHED_FIFO prio 1 alone enables unprivileged users to lock
up the system.

so i could agree with RLIMIT_NICE (which _is_ a limit), but
RLIMIT_RTPRIO sends the wrong message. The proper rlimit would be
RLIMIT_RT_CPU (the patch i did).

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall <[EMAIL PROTECTED]> wrote:

> Read more closely: there are two independent limits in the patch,
> RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
> without SCHED_FIFO.

ok, indeed.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> > i disagree that desktop performance tomorrow will necessarily have to
> > utilize SCHED_FIFO. Today's desktop audio applications perform quite
> > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
> > interactivity/latency fixes such as PREEMPT_BKL].
> 
> Desktop performance tomorrow will want realtime audio AND video. 
> Think simultaneous record and playback of multiple high-definition
> video streams. There's a demand for this; my company already sells it.

Tomorrow's hardware will have enough buffering as today's hardware has
for simpler tasks. Repeat after me: it likely _wont_ _need_ SCHED_FIFO.
Running tomorrow's hardware on today's boxes indeed pushes the system to
its limits, but torrows hardware will be well-balanced just as much as
today's is - if nothing else then due to kernel drivers providing a
buffering guarantee.

think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
can be useful if you _need_ a scheduling guarantee due to physical
constraints, and it can be useful if the hardware (or the kernel) cannot
buffer enough, but otherwise, it only causes problems.

> I'm very suspicious about being able to rip out RT-LSM once it's
> introduced. [...]

yeah, i somewhat share that view. (despite all the promises from the
audio folks - if they are just half as agressive resisting removal as
they were pushing integration then it will never be removed ;-)

but i'm not sure how rlimits will contain the whole problem - can
rlimits be restricted to a single app (jackd)? The most canonical use of
rlimits is per-user (per-group), so the rlimit could end up _widening_
the effects of the hack ...

> > > The rlimit stuff is not perfect, but it's a much better fit for the
> > > UNIX model generally, which is a fairly big win. [...]
> > 
> > a 'locked up box' is as far away from the UNIX model as it gets.
> 
> Rlimits are already the favored tool for dealing with the classic UNIX
> DoS: the fork bomb. Turn off process limits, tada, locked up box.

the big difference is that process limits are finegrained and it has a
single value (unlimited) that allows the DoS - while the RT-rlimits have
_one_ value that is safe, all the other values are unsafe!

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:48:43AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
> 
> > Here's Chris' patch for reference:
> > 
> > http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
> 
> how does this patch solve the separation of 'negative nice values' and
> 'RT priority rlimits'? In one piece of code it handles the rlimit value
> as a 0-39 nice value, in another place it handles it as a limit for a
> 1-100 RT priority range. The two ranges overlap and have nothing to do
> with each other. [*]

Read more closely: there are two independent limits in the patch,
RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
without SCHED_FIFO.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> Here's Chris' patch for reference:
> 
> http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80

how does this patch solve the separation of 'negative nice values' and
'RT priority rlimits'? In one piece of code it handles the rlimit value
as a 0-39 nice value, in another place it handles it as a limit for a
1-100 RT priority range. The two ranges overlap and have nothing to do
with each other. [*]

anyway, as long as it doesnt touch the scheduler runtime code (and it
doesnt), both types of solutions are fine to me - it's basically the
security-subsystem people's call.

if the patch solves the negative-nice-value and the RT-priority issues
at once, then it indeed looks more flexible (and more generic) than the
LSM solution. [**]

Ingo

[*]  one acceptable way to 'merge' the two priority ranges would be to
 introduce a unified priority range of 0-139: 0-39 would be for nice
 values while 40-139 would be for RT priorities 1-99. NOTE: due to
 rlimit semantics (users can always lower them without any security
 checks), value 39 _must_ denote nice -20 and value 0 must denote
 nice +19. I.e. it must strictly in increasing priority order.

[**] in fact, the 'Gnome problem' wrt. suid/gid binaries would be solved 
 via the rlimit too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
> 
> > I think it's important to recognize that we're trying to address an
> > issue that has a much wider potential audience than pro audio users,
> > and not very far off - what is high end audio performance today will
> > be expected desktop performance next year.
> 
> i disagree that desktop performance tomorrow will necessarily have to
> utilize SCHED_FIFO. Today's desktop audio applications perform quite
> good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
> interactivity/latency fixes such as PREEMPT_BKL].

Desktop performance tomorrow will want realtime audio AND video. 
Think simultaneous record and playback of multiple high-definition
video streams. There's a demand for this; my company already sells it.
 
> the pro applications will always want to have a 100% guarantee (it
> really sucks to generate a nasty audio click during a live performance)
> and want to utilize as much CPU time for audio as needed. They are also
> clearly the most complex creators of audio so they go far above the
> normal (and reasonable) CPU-use/latency expectations and tradeoffs of
> the stock scheduler.

The pro will want to do his work on a stock desktop system. More
importantly, the hobbyist will want to do exactly what the pro is
doing on the same system. 

> > So I think it's critical that we find solution that's appropriate for
> > _every single box_, because realistically vendors are going to ship
> > with this "wholly self-contained" feature turned on by default next
> > year, at which point the "containment" will be nil and whatever warts
> > it has will be with us forever.
> 
> an "RT priorities rlimit" is still not adequate as a desktop solution,
> because it still allows the box to be locked up. Also, if it turns out
> to be a mistake then it's already codified into the ABI, while RT-LSM is
> much less 'persistent' and could be replaced much easier. RT-LSM is also
> more flexible and more practical. (an rlimit needs changes across a
> number of userspace components, delaying its adoptation.)

I'm very suspicious about being able to rip out RT-LSM once it's
introduced. See devfs. And I think the adoption barrier thing is a red
herring as well: the current users are by and large compiling their
own RT-tuned kernels.

> > The rlimit stuff is not perfect, but it's a much better fit for the
> > UNIX model generally, which is a fairly big win. [...]
> 
> a 'locked up box' is as far away from the UNIX model as it gets.

Rlimits are already the favored tool for dealing with the classic UNIX DoS:
the fork bomb. Turn off process limits, tada, locked up box.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 08:54:17AM +0100, Ingo Molnar wrote:
> 
> * Matt Mackall <[EMAIL PROTECTED]> wrote:
> 
> > Eh? Chris Wright's original rlimits patch was very straightforward
> > [...]
> 
> the problem is that it didnt solve the problem (unprivileged user can
> lock up the system) in any way.

There are two separate but related problems:

a) need a way to give non-root access to SCHED_FIFO without other
privileges

b) would like a way to have RT-like capabilities without risk of DoS

The original rlimits patch solves (a), which is the pressing concern.

The existence of a satisfactory solution to related problem (b) has
yet to be demonstrated. And even if a solution for (b) is found that
is satisfactory for, say, high end audio users, it may not necessarily
be sufficient for everyone who might have wanted SCHED_FIFO for
non-root processes. So we still need a solution for (a).

> So after it became visible that all the
> existing 'dont allow users to lock up' solutions are too invasive, we
> went to recommend the solution that introduces the least architectural
> problems: RT-LSM.

RT-LSM introduces architectural problems in the form of bogus API. And
I claim that if RT-LSM becomes part of the mainline kernel, it -will-
become a default feature on the desktop in short order. The fact that
it's implemented as an LSM is meaningless if Redhat and SuSE ship it
on by default.

So the comparison boils down to putting a magic gid in a sysfs
file/module parameter or setting an rlimit with standard tools (PAM,
etc). I'm really boggled that anyone could prefer the former,
especially since we had almost this exact debate over what became the
mlock rlimit!

Here's Chris' patch for reference:

http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Christoph Hellwig

On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
> an "RT priorities rlimit" is still not adequate as a desktop solution,
> because it still allows the box to be locked up. Also, if it turns out
> to be a mistake then it's already codified into the ABI, while RT-LSM is
> much less 'persistent' and could be replaced much easier. RT-LSM is also
> more flexible and more practical. (an rlimit needs changes across a
> number of userspace components, delaying its adoptation.)

Putting it into the tree means a gurantee we'll keep it going.  It'd
probably much better if Jack just keepts it separatly.  Especially as
his lack of even making it generic shows that he's unwilling to invest
work into it that doesn't benfit him personally.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> > > What happened to the RT rlimit code from Chris?
> > 
> > I still have it, but I had the impression Ingo didn't like it as a long
> > term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> > patch is wholly self-contained.
> 
> I think it's important to recognize that we're trying to address an
> issue that has a much wider potential audience than pro audio users,
> and not very far off - what is high end audio performance today will
> be expected desktop performance next year.

i disagree that desktop performance tomorrow will necessarily have to
utilize SCHED_FIFO. Today's desktop audio applications perform quite
good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
interactivity/latency fixes such as PREEMPT_BKL].

I agree (and hope) that tomorrow's "stock" desktop will be based on
today's pro audio architectures, but tomorrows CPUs will be much faster
and tomorrows desktop apps dont want to spend 30%+ CPU time on creating
audio.

the pro applications will always want to have a 100% guarantee (it
really sucks to generate a nasty audio click during a live performance)
and want to utilize as much CPU time for audio as needed. They are also
clearly the most complex creators of audio so they go far above the
normal (and reasonable) CPU-use/latency expectations and tradeoffs of
the stock scheduler.

> So I think it's critical that we find solution that's appropriate for
> _every single box_, because realistically vendors are going to ship
> with this "wholly self-contained" feature turned on by default next
> year, at which point the "containment" will be nil and whatever warts
> it has will be with us forever.

an "RT priorities rlimit" is still not adequate as a desktop solution,
because it still allows the box to be locked up. Also, if it turns out
to be a mistake then it's already codified into the ABI, while RT-LSM is
much less 'persistent' and could be replaced much easier. RT-LSM is also
more flexible and more practical. (an rlimit needs changes across a
number of userspace components, delaying its adoptation.)

> The rlimit stuff is not perfect, but it's a much better fit for the
> UNIX model generally, which is a fairly big win. [...]

a 'locked up box' is as far away from the UNIX model as it gets.

perhaps, if the need arises, we can add the RT-throttling sysctl (which
still wont give RT priorities to unprivileged users and would serve as a
way to throttle privileged RT tasks), which could thus make the RT-LSM
solution pretty safe. Right now Jack has its own watchdog thread which
should solve most of the lockup situations.  Lets not overdesign the
solution, especially when we dont yet know how the problem really looks
like.

or an even simpler solution for the lockup problem would be a
kernel-based RT watchdog. In fact 2.6.11-rc3-mm2 already includes such a
watchdog (written by yours truly):

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/broken-out/detect-soft-lockups.patch

right now softlockup-detect runs at SCHED_FIFO prio 99 and only prints a
warning - but it could easily run at SCHED_FIFO prio 1 [to detect
lockups generated by all RT tasks] and it could actively try to renice
(or kill) tasks that run for too long. So very likely there will be an
easy upstream mechanism for any problem that could arise out of RT-LSM.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

* Matt Mackall [EMAIL PROTECTED] wrote:

What happened to the RT rlimit code from Chris?

I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm
patch is wholly self-contained.

I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will
be expected desktop performance next year.

i disagree that desktop performance tomorrow will necessarily have to
utilize SCHED_FIFO. Today's desktop audio applications perform quite
good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
interactivity/latency fixes such as PREEMPT_BKL].

I agree (and hope) that tomorrow's stock desktop will be based on
today's pro audio architectures, but tomorrows CPUs will be much faster
and tomorrows desktop apps dont want to spend 30%+ CPU time on creating
audio.

the pro applications will always want to have a 100% guarantee (it
really sucks to generate a nasty audio click during a live performance)
and want to utilize as much CPU time for audio as needed. They are also
clearly the most complex creators of audio so they go far above the
normal (and reasonable) CPU-use/latency expectations and tradeoffs of
the stock scheduler.

So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this wholly self-contained feature turned on by default next
year, at which point the containment will be nil and whatever warts
it has will be with us forever.

an RT priorities rlimit is still not adequate as a desktop solution,
because it still allows the box to be locked up. Also, if it turns out
to be a mistake then it's already codified into the ABI, while RT-LSM is
much less 'persistent' and could be replaced much easier. RT-LSM is also
more flexible and more practical. (an rlimit needs changes across a
number of userspace components, delaying its adoptation.)

The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. [...]

a 'locked up box' is as far away from the UNIX model as it gets.

perhaps, if the need arises, we can add the RT-throttling sysctl (which
still wont give RT priorities to unprivileged users and would serve as a
way to throttle privileged RT tasks), which could thus make the RT-LSM
solution pretty safe. Right now Jack has its own watchdog thread which
should solve most of the lockup situations. Lets not overdesign the
solution, especially when we dont yet know how the problem really looks
like.

or an even simpler solution for the lockup problem would be a
kernel-based RT watchdog. In fact 2.6.11-rc3-mm2 already includes such a
watchdog (written by yours truly):

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/broken-out/detect-soft-lockups.patch

right now softlockup-detect runs at SCHED_FIFO prio 99 and only prints a
warning - but it could easily run at SCHED_FIFO prio 1 [to detect
lockups generated by all RT tasks] and it could actively try to renice
(or kill) tasks that run for too long. So very likely there will be an
easy upstream mechanism for any problem that could arise out of RT-LSM.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Christoph Hellwig

On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
 an RT priorities rlimit is still not adequate as a desktop solution,
 because it still allows the box to be locked up. Also, if it turns out
 to be a mistake then it's already codified into the ABI, while RT-LSM is
 much less 'persistent' and could be replaced much easier. RT-LSM is also
 more flexible and more practical. (an rlimit needs changes across a
 number of userspace components, delaying its adoptation.)

Putting it into the tree means a gurantee we'll keep it going.  It'd
probably much better if Jack just keepts it separatly.  Especially as
his lack of even making it generic shows that he's unwilling to invest
work into it that doesn't benfit him personally.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 08:54:17AM +0100, Ingo Molnar wrote:
 
 * Matt Mackall [EMAIL PROTECTED] wrote:
 
  Eh? Chris Wright's original rlimits patch was very straightforward
  [...]
 
 the problem is that it didnt solve the problem (unprivileged user can
 lock up the system) in any way.

There are two separate but related problems:

a) need a way to give non-root access to SCHED_FIFO without other
privileges

b) would like a way to have RT-like capabilities without risk of DoS

The original rlimits patch solves (a), which is the pressing concern.

The existence of a satisfactory solution to related problem (b) has
yet to be demonstrated. And even if a solution for (b) is found that
is satisfactory for, say, high end audio users, it may not necessarily
be sufficient for everyone who might have wanted SCHED_FIFO for
non-root processes. So we still need a solution for (a).

 So after it became visible that all the
 existing 'dont allow users to lock up' solutions are too invasive, we
 went to recommend the solution that introduces the least architectural
 problems: RT-LSM.

RT-LSM introduces architectural problems in the form of bogus API. And
I claim that if RT-LSM becomes part of the mainline kernel, it -will-
become a default feature on the desktop in short order. The fact that
it's implemented as an LSM is meaningless if Redhat and SuSE ship it
on by default.

So the comparison boils down to putting a magic gid in a sysfs
file/module parameter or setting an rlimit with standard tools (PAM,
etc). I'm really boggled that anyone could prefer the former,
especially since we had almost this exact debate over what became the
mlock rlimit!

Here's Chris' patch for reference:

http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote:
 
  I think it's important to recognize that we're trying to address an
  issue that has a much wider potential audience than pro audio users,
  and not very far off - what is high end audio performance today will
  be expected desktop performance next year.
 
 i disagree that desktop performance tomorrow will necessarily have to
 utilize SCHED_FIFO. Today's desktop audio applications perform quite
 good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
 interactivity/latency fixes such as PREEMPT_BKL].

Desktop performance tomorrow will want realtime audio AND video. 
Think simultaneous record and playback of multiple high-definition
video streams. There's a demand for this; my company already sells it.
 
 the pro applications will always want to have a 100% guarantee (it
 really sucks to generate a nasty audio click during a live performance)
 and want to utilize as much CPU time for audio as needed. They are also
 clearly the most complex creators of audio so they go far above the
 normal (and reasonable) CPU-use/latency expectations and tradeoffs of
 the stock scheduler.

The pro will want to do his work on a stock desktop system. More
importantly, the hobbyist will want to do exactly what the pro is
doing on the same system. 

  So I think it's critical that we find solution that's appropriate for
  _every single box_, because realistically vendors are going to ship
  with this wholly self-contained feature turned on by default next
  year, at which point the containment will be nil and whatever warts
  it has will be with us forever.
 
 an RT priorities rlimit is still not adequate as a desktop solution,
 because it still allows the box to be locked up. Also, if it turns out
 to be a mistake then it's already codified into the ABI, while RT-LSM is
 much less 'persistent' and could be replaced much easier. RT-LSM is also
 more flexible and more practical. (an rlimit needs changes across a
 number of userspace components, delaying its adoptation.)

I'm very suspicious about being able to rip out RT-LSM once it's
introduced. See devfs. And I think the adoption barrier thing is a red
herring as well: the current users are by and large compiling their
own RT-tuned kernels.

  The rlimit stuff is not perfect, but it's a much better fit for the
  UNIX model generally, which is a fairly big win. [...]
 
 a 'locked up box' is as far away from the UNIX model as it gets.

Rlimits are already the favored tool for dealing with the classic UNIX DoS:
the fork bomb. Turn off process limits, tada, locked up box.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

 Here's Chris' patch for reference:
 
 http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80

how does this patch solve the separation of 'negative nice values' and
'RT priority rlimits'? In one piece of code it handles the rlimit value
as a 0-39 nice value, in another place it handles it as a limit for a
1-100 RT priority range. The two ranges overlap and have nothing to do
with each other. [*]

anyway, as long as it doesnt touch the scheduler runtime code (and it
doesnt), both types of solutions are fine to me - it's basically the
security-subsystem people's call.

if the patch solves the negative-nice-value and the RT-priority issues
at once, then it indeed looks more flexible (and more generic) than the
LSM solution. [**]

Ingo

[*]  one acceptable way to 'merge' the two priority ranges would be to
 introduce a unified priority range of 0-139: 0-39 would be for nice
 values while 40-139 would be for RT priorities 1-99. NOTE: due to
 rlimit semantics (users can always lower them without any security
 checks), value 39 _must_ denote nice -20 and value 0 must denote
 nice +19. I.e. it must strictly in increasing priority order.

[**] in fact, the 'Gnome problem' wrt. suid/gid binaries would be solved 
 via the rlimit too.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:48:43AM +0100, Ingo Molnar wrote:
 
 * Matt Mackall [EMAIL PROTECTED] wrote:
 
  Here's Chris' patch for reference:
  
  http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80
 
 how does this patch solve the separation of 'negative nice values' and
 'RT priority rlimits'? In one piece of code it handles the rlimit value
 as a 0-39 nice value, in another place it handles it as a limit for a
 1-100 RT priority range. The two ranges overlap and have nothing to do
 with each other. [*]

Read more closely: there are two independent limits in the patch,
RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
without SCHED_FIFO.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

  i disagree that desktop performance tomorrow will necessarily have to
  utilize SCHED_FIFO. Today's desktop audio applications perform quite
  good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
  interactivity/latency fixes such as PREEMPT_BKL].
 
 Desktop performance tomorrow will want realtime audio AND video. 
 Think simultaneous record and playback of multiple high-definition
 video streams. There's a demand for this; my company already sells it.

Tomorrow's hardware will have enough buffering as today's hardware has
for simpler tasks. Repeat after me: it likely _wont_ _need_ SCHED_FIFO.
Running tomorrow's hardware on today's boxes indeed pushes the system to
its limits, but torrows hardware will be well-balanced just as much as
today's is - if nothing else then due to kernel drivers providing a
buffering guarantee.

think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
can be useful if you _need_ a scheduling guarantee due to physical
constraints, and it can be useful if the hardware (or the kernel) cannot
buffer enough, but otherwise, it only causes problems.

 I'm very suspicious about being able to rip out RT-LSM once it's
 introduced. [...]

yeah, i somewhat share that view. (despite all the promises from the
audio folks - if they are just half as agressive resisting removal as
they were pushing integration then it will never be removed ;-)

but i'm not sure how rlimits will contain the whole problem - can
rlimits be restricted to a single app (jackd)? The most canonical use of
rlimits is per-user (per-group), so the rlimit could end up _widening_
the effects of the hack ...

   The rlimit stuff is not perfect, but it's a much better fit for the
   UNIX model generally, which is a fairly big win. [...]
  
  a 'locked up box' is as far away from the UNIX model as it gets.
 
 Rlimits are already the favored tool for dealing with the classic UNIX
 DoS: the fork bomb. Turn off process limits, tada, locked up box.

the big difference is that process limits are finegrained and it has a
single value (unlimited) that allows the DoS - while the RT-rlimits have
_one_ value that is safe, all the other values are unsafe!

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

 Read more closely: there are two independent limits in the patch,
 RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice
 without SCHED_FIFO.

ok, indeed.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

 So the comparison boils down to putting a magic gid in a sysfs
 file/module parameter or setting an rlimit with standard tools (PAM,
 etc). I'm really boggled that anyone could prefer the former,
 especially since we had almost this exact debate over what became the
 mlock rlimit!

the big difference to mlock is that for mlock there _is_ a _limit_. For
RT scheduling the priority is _NOT_ a _limit_. Okay? So you give the
false pretense of this being some kind of resource 'limit', while in
fact allowing SCHED_FIFO prio 1 alone enables unprivileged users to lock
up the system.

so i could agree with RLIMIT_NICE (which _is_ a limit), but
RLIMIT_RTPRIO sends the wrong message. The proper rlimit would be
RLIMIT_RT_CPU (the patch i did).

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 10:04:19AM +0100, Ingo Molnar wrote:
 
 * Matt Mackall [EMAIL PROTECTED] wrote:
 
  So the comparison boils down to putting a magic gid in a sysfs
  file/module parameter or setting an rlimit with standard tools (PAM,
  etc). I'm really boggled that anyone could prefer the former,
  especially since we had almost this exact debate over what became the
  mlock rlimit!
 
 the big difference to mlock is that for mlock there _is_ a _limit_. For
 RT scheduling the priority is _NOT_ a _limit_. Okay? So you give the
 false pretense of this being some kind of resource 'limit', while in
 fact allowing SCHED_FIFO prio 1 alone enables unprivileged users to lock
 up the system.

 so i could agree with RLIMIT_NICE (which _is_ a limit), but
 RLIMIT_RTPRIO sends the wrong message. The proper rlimit would be
 RLIMIT_RT_CPU (the patch i did).

It's not a perfect fit, I'll readily agree.

But consider this: with RLIMIT_RTPRIO, I can restrict a user to the
lowest N RT priorities. Then at N+1, I have an RT watchdog taking care
of runaways, tickled by a SCHED_NORMAL task. So it can still be looked
at as a meaningful limit, just a bit different from the others.

The RT LSM gives full CAP_SYS_NICE out, so there's no way to guarantee
that the watchdog has higher priority.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
 
 think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
 destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
 can be useful if you _need_ a scheduling guarantee due to physical
 constraints, and it can be useful if the hardware (or the kernel) cannot
 buffer enough, but otherwise, it only causes problems.

Agreed. I think something short of full SCHED_FIFO will make most
desktop folks happy. But a) we still have to figure out exactly how to
do that and b) we still have to make everyone else happy. The embedded
folks (me included) would prefer to not run our realtime bits as root
too..

 but i'm not sure how rlimits will contain the whole problem - can
 rlimits be restricted to a single app (jackd)?

Yes. There's also the whole soft limit thing.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

 On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
  
  think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
  destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
  can be useful if you _need_ a scheduling guarantee due to physical
  constraints, and it can be useful if the hardware (or the kernel) cannot
  buffer enough, but otherwise, it only causes problems.
 
 Agreed. I think something short of full SCHED_FIFO will make most
 desktop folks happy. [...]

ah, but it's not the desktop folks who have to be happy but users :-)
Really, if you ask any app designer then obviously 'the more CPU time we
get for sure, the better our app behaves'. So in that sense SCHED_OTHER
is a fair playground: if you behave nicely you'll have higher priority
and shorter latencies.

(there are things like SCHED_ISO but how good of a solution they are is
not yet clear.)

 [...] But a) we still have to figure out exactly how to do that and b)
 we still have to make everyone else happy. The embedded folks (me
 included) would prefer to not run our realtime bits as root too..

you dont have to - you can drop root after startup.

  but i'm not sure how rlimits will contain the whole problem - can
  rlimits be restricted to a single app (jackd)?
 
 Yes. There's also the whole soft limit thing.

i'm curious, how does this 'per-app' rlimit thing work? If a user has
jackd installed and runs it from X unprivileged, how does it get the
elevated rlimit? (while the rest of his desktop still runs with a safe
rlimit.) SELinux/RT-LSM could do this, but i'm not sure about how
rlimits give this to you.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Yuval Tanny

In fs/Kconfig,
See Documentation/filesystems/fscache.txt for more information. and 
See Documentation/filesystems/cachefs.txt for more information.

Should be changed to:
See Documentation/filesystems/caching/fscache.txt for more 
information. and See Documentation/filesystems/caching/cachefs.txt for 
more information.

Thanks,
Yuval
Andrew Morton wrote:
cachefs-filesystem.patch
 CacheFS filesystem
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Paul Davis

introduced. See devfs. And I think the adoption barrier thing is a red
herring as well: the current users are by and large compiling their
own RT-tuned kernels.

not true. most people are using kernels built for specialized distros
or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic.

--p
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2


* Matt Mackall [EMAIL PROTECTED] wrote:

   Yes. There's also the whole soft limit thing.
  
  i'm curious, how does this 'per-app' rlimit thing work? If a user has
  jackd installed and runs it from X unprivileged, how does it get the
  elevated rlimit?
 
 It needs a setuid launcher. It would be nice to be able to elevate the
 rlimits of running processes but the API doesn't exist yet.

With a setuid launcher you need _zero_ kernel help to get SCHED_FIFO: if
you have a launcher then already today it can just give SCHED_FIFO to
jackd and be done with it!

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 10:53:27AM +0100, Ingo Molnar wrote:
 
 * Matt Mackall [EMAIL PROTECTED] wrote:
 
  On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote:
   
   think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
   destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
   can be useful if you _need_ a scheduling guarantee due to physical
   constraints, and it can be useful if the hardware (or the kernel) cannot
   buffer enough, but otherwise, it only causes problems.
  
  Agreed. I think something short of full SCHED_FIFO will make most
  desktop folks happy. [...]
 
 ah, but it's not the desktop folks who have to be happy but users :-)
 Really, if you ask any app designer then obviously 'the more CPU time we
 get for sure, the better our app behaves'. So in that sense SCHED_OTHER
 is a fair playground: if you behave nicely you'll have higher priority
 and shorter latencies.
 
 (there are things like SCHED_ISO but how good of a solution they are is
 not yet clear.)
 
  [...] But a) we still have to figure out exactly how to do that and b)
  we still have to make everyone else happy. The embedded folks (me
  included) would prefer to not run our realtime bits as root too..
 
 you dont have to - you can drop root after startup.
 
   but i'm not sure how rlimits will contain the whole problem - can
   rlimits be restricted to a single app (jackd)?
  
  Yes. There's also the whole soft limit thing.
 
 i'm curious, how does this 'per-app' rlimit thing work? If a user has
 jackd installed and runs it from X unprivileged, how does it get the
 elevated rlimit?

It needs a setuid launcher. It would be nice to be able to elevate the
rlimits of running processes but the API doesn't exist yet.

From the POV of accidental elevation to RT, soft limits are
sufficient. But we can't stop a user from exploiting an app they own
with RT privileges from elevating other apps via ptrace+exec or
whatever. Nor with RT-LSM.

 (while the rest of his desktop still runs with a safe
 rlimit.) SELinux/RT-LSM could do this, but i'm not sure about how
 rlimits give this to you.

How does it get done with RT-LSM? Setgid binaries? It only
discriminates on a group granularity. Or are you saying and SELinux
rather than or SELinux?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
 RT-LSM introduces architectural problems in the form of bogus API. And
 
 that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
 introduce *any* API whatsoever - it simply allows software to call
 various existing APIs (mostly from POSIX) and have them not fail as
 result of not being root and/or not running on a capabilities-enabled
 kernel without the required caps.

The API is the parameters to modprobe or sysfs. 

 it's implemented as an LSM is meaningless if Redhat and SuSE ship it
 on by default.
 
 We haven't encouraged anyone to ship anything with it on by default:
 the idea is for the module to be present and usable, not turned on.

On as in turned on for build in the kernel config and shipped. But I
expect people will eventually actually ship it _on_ with a group
called 'rt' and possibly even put the primary user in there on install
unless you start slapping some big fat warnings on it. (I just noticed
the new Debian installer is putting the primary user in audio, cdrom,
video, etc.)

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Lee Revell

On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote:
 On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote:
  RT-LSM introduces architectural problems in the form of bogus API. And
  
  that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't
  introduce *any* API whatsoever - it simply allows software to call
  various existing APIs (mostly from POSIX) and have them not fail as
  result of not being root and/or not running on a capabilities-enabled
  kernel without the required caps.
 
 The API is the parameters to modprobe or sysfs. 
 

I think you are talking about the API for root to administer it vs. the
(lack of) API for apps to use the RT capabilities.  I think Paul's point
is that we can transparently replace it with something better (IMO the
RT rlimit is better) in the future, and the apps don't have to know
about it at all.  Comparing it to devfs/udev is bogus because those are
way, way more complicated.

  it's implemented as an LSM is meaningless if Redhat and SuSE ship it
  on by default.
  
  We haven't encouraged anyone to ship anything with it on by default:
  the idea is for the module to be present and usable, not turned on.
 
 On as in turned on for build in the kernel config and shipped. But I
 expect people will eventually actually ship it _on_ with a group
 called 'rt' and possibly even put the primary user in there on install
 unless you start slapping some big fat warnings on it. (I just noticed
 the new Debian installer is putting the primary user in audio, cdrom,
 video, etc.)
 

Sorry, if the distros are so dumb they need a big fat warning to know
that this is not a safe thing to enable by default, at least on anything
you would ever consider a multiuser system, then they get what they
deserve.  If they have half a brain they will use the setgid approach
that Ingo suggested, and only enable this for apps like JACK and
cdrecord that have been farily well audited and can be trusted to use
this feature (for example JACK has the internal watchdog to keep a bad
client from locking the system).  Really it only makes sense for a
distro to enable this if the user selects the low latency desktop or
multimedia desktop or whatever install option and makes clear that
this profile is NOT suitable for a multiuser system. 

Lee

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote:
 
 * Matt Mackall [EMAIL PROTECTED] wrote:
 
Yes. There's also the whole soft limit thing.
   
   i'm curious, how does this 'per-app' rlimit thing work? If a user has
   jackd installed and runs it from X unprivileged, how does it get the
   elevated rlimit?
  
  It needs a setuid launcher. It would be nice to be able to elevate the
  rlimits of running processes but the API doesn't exist yet.
 
 With a setuid launcher you need _zero_ kernel help to get SCHED_FIFO: if
 you have a launcher then already today it can just give SCHED_FIFO to
 jackd and be done with it!

I'm sure you know all this already but I'll spell it out so we're all
clear:

a) rlimits are tracked per-process so they're fundamentally
per-process
b) there are hard and soft limits, with soft always = hard
c) only root can raise hard rlimits, but normal users can lower them
d) if a user owns a process, he can gain the privileges of that process
by various means, so in the strict sense per-process privileges are
meaningless - all privileges are per-uid
e) so we either need to segregate all privileged processes into
separate uid domains
f) or we're assuming non-malicious users and soft limits are
sufficient.

Now I suspect we don't want to insist people do (e) (though I'd
certainly encourage them to try).

Don't forget that the rlimits approach allows us to reserve the
highest priorities for root. I'm pretty sure an effective watchdog
policy can thus be implemented in userspace, which RT-LSM can't really
offer.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Ingo Molnar

* Matt Mackall <[EMAIL PROTECTED]> wrote:

> Eh? Chris Wright's original rlimits patch was very straightforward
> [...]

the problem is that it didnt solve the problem (unprivileged user can
lock up the system) in any way. So after it became visible that all the
existing 'dont allow users to lock up' solutions are too invasive, we
went to recommend the solution that introduces the least architectural
problems: RT-LSM.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, Feb 10, 2005 at 10:41:28PM -0500, Paul Davis wrote:
>   [ the best solution is  ]
> 
>   [ my preferred solution is ... ]
> 
>   [ it would be better if ... ]
> 
>   [ this is a kludge and it should be done instead like ... ]
> 
> did nobody read what andrew wrote and what JOQ pointed out?
> 
> after weeks of debating this, no other conceptual solution emerged
> that did not have at least as many problems as the RT LSM module, and
> all other proposed solutions were also more invasive of other aspects
> of kernel design and operations than RT LSM is.

Eh? Chris Wright's original rlimits patch was very straightforward
(unlike some of the other rlimit-like patches that followed).
I haven't heard the downsides of it yet.

simple rlimits:
 logical extension of standard, flexible interface
 fine-grained per-process access to nice levels and priorities
 managed with standard tools
 fairly broad possible applications
 clean enough to be added unconditionally
 already doing mlock this way!

RT LSM:
 new, narrow magic group interface (module parameters!)
 boolean granularity of access to all RT levels and maybe mlock
 potential interesting interaction with other LSMs
 not orthogonal to mlock
 not appropriate for every box out there
 requires lsm and (sysfs or modprobe)

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, 2005-02-11 at 17:34 +1100, Peter Williams wrote:
> Nick Piggin wrote:

> > I can't say much about it because I'm not putting my hand up to
> > do anything. Just mentioning that rlimit would be better if not
> > for the userspace side of the equation. I think most were already
> > agreed on that point anyway though.
> 
> I think that the rlimits are a good idea in themselves but not as a 
> solution to this problem.  I.e. having a RT CPU rate rlimit should not 
> be a sufficient (or necessary for that matter) condition to change 
> policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
> possibility of lock out.

Ah well that may be a good way to do it indeed. As I said, I
don't know much about privileges etc.

But I just want to be clear that I'm not trying to stop RT-LSM
going in (if only because I don't care one way or the other
about it).

>   (But I guess even that is a violation of RT 
> semantics?)
> 

I'd have to re-read the standard, but it may not be. For example,
a compliant system advertises the minimum and maximum priority
levels available - you may be able to adjust these based on what
the rlimit is set to. On the other hand, yes it may violate the
stanards.

Nick

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Nick Piggin wrote:
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
 [ the best solution is  ]
 [ my preferred solution is ... ]
 [ it would be better if ... ]
 [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.
I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.
I think that the rlimits are a good idea in themselves but not as a 
solution to this problem.  I.e. having a RT CPU rate rlimit should not 
be a sufficient (or necessary for that matter) condition to change 
policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
possibility of lock out.  (But I guess even that is a violation of RT 
semantics?)

Peter
PS Zaphod's per task hard/soft CPU rate caps (which are the equivalent 
of an rlimit on CPU usage rate) are only enforced for SCHED_NORMAL tasks 
and should not (therefore) effect RT semantics.
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2 (compile stats)

2005-02-10 Thread John Cherry

Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

KernelbzImage   bzImage  bzImage  modules  bzImage  modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--- --     
2.6.11-rc3-mm2   14w/0e 0w/0e   192w/0e6w/0e  19w/0e172w/0e
2.6.11-rc3-mm1   13w/10e0w/7e   196w/12e   6w/0e  18w/12e   177w/0e
2.6.11-rc2-mm2   15w/0e 0w/0e   201w/0e6w/0e  18w/0e182w/0e
2.6.11-rc2-mm1   15w/0e 0w/0e   306w/14e   6w/0e  18w/0e294w/0e
2.6.11-rc1-mm2   21w/0e 0w/0e   316w/9e6w/0e  22w/0e294w/0e
2.6.11-rc1-mm1   21w/0e 0w/0e   319w/0e6w/0e  23w/0e298w/0e
2.6.10-mm3   21w/0e 0w/0e   320w/0e6w/0e  23w/0e299w/0e
2.6.10-mm2   21w/0e 0w/0e   440w/0e6w/0e  23w/0e420w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-rc1-mm1   16w/1e 1w/1e   592w/1e4w/0e  13w/1e857w/0e
2.6.9-mm1 6w/1e 1w/1e  1761w/15e  65w/0e   9w/0e   2086w/0e
2.6.9-rc4-mm1 5w/0e 0w/0e  1766w/11e  43w/0e   6w/0e   1798w/0e
2.6.9-rc3-mm3 5w/0e 0w/0e  1756w/11e  43w/0e   4w/0e   1786w/0e
2.6.9-rc3-mm210w/0e 4w/9e  1754w/14e  43w/0e   4w/0e   1782w/1e
2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e   43w/0e   4w/0e   1796w/0e
2.6.9-rc2-mm410w/0e 5w/0e  2573w/0e   41w/0e   4w/0e   2600w/0e
2.6.9-rc2-mm310w/0e 5w/0e  2400w/0e   41w/0e   4w/0e   2435w/0e
2.6.9-rc2-mm210w/0e 5w/0e  2919w/0e   41w/0e   4w/0e   2954w/0e
2.6.9-rc2-mm1 0w/0e 2w/0e  3541w/9e   41w/0e   3w/9e   3567w/0e
2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e   2w/0e 48w/0e
2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e   3w/0e   1w/0e 49w/1e
2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e   3w/0e   1w/0e 47w/0e
2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e   1w/0e 74w/0e
2.6.8.1-mm4   0w/0e 0w/0e78w/0e4w/0e   1w/0e 73w/0e
2.6.8.1-mm3   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm2   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm1   0w/0e 0w/0e78w/0e4w/0e   1w/0e 74w/0e
2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e   1w/0e 75w/0e
2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e   2w/8e 75w/0e
2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e   1w/0e 75w/0e
2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e   1w/0e 80w/0e
2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e   1w/0e 81w/0e
2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e   1w/0e 87w/0e
2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e   1w/0e 84w/0e
2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e   1w/0e 80w/0e
2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e   1w/0e 87w/0e
2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e   1w/0e 89w/0e
2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e   1w/0e 86w/0e
2.6.7-mm2 0w/0e 0w/0e   109w/0e7w/0e   1w/0e106w/0e
2.6.7-mm1 0w/0e 5w/0e   108w/0e5w/0e   1w/0e104w/0e
2.6.7-rc3-mm2 0w/0e 5w/0e   105w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc3-mm1 0w/0e 5w/0e   104w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc2-mm2 0w/0e 5w/0e   109w/10e   5w/0e   2w/0e105w/2e
2.6.7-rc2-mm1 0w/0e12w/0e   158w/13e   5w/0e   3w/0e153w/4e
2.6.7-rc1-mm1 0w/0e 6w/0e   108w/0e

Re: 2.6.11-rc3-mm2

Paul Davis wrote:
  [ the best solution is  ]
  [ my preferred solution is ... ]
  [ it would be better if ... ]
  [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.
As I see it, what I said was in support of RT LSM (or at least the 
approach that RT LSM is taking) so why are you attacking me.  I'm on 
your side :-)

Peter
PS I'm withdrawing the "unprivileged real time" feature from the 
spa_no_frills and zaphod schedulers in the PlugSched patch as a result 
of the discussions on SCHED_ISO and RT rlimits because the discussion 
convinced me that it's the wrong way to go.
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
>   [ the best solution is  ]
> 
>   [ my preferred solution is ... ]
> 
>   [ it would be better if ... ]
> 
>   [ this is a kludge and it should be done instead like ... ]
> 
> did nobody read what andrew wrote and what JOQ pointed out?
> 
> after weeks of debating this, no other conceptual solution emerged
> that did not have at least as many problems as the RT LSM module, and
> all other proposed solutions were also more invasive of other aspects
> of kernel design and operations than RT LSM is.
> 

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.

I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.

Nick




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Paul Davis

  [ the best solution is  ]

  [ my preferred solution is ... ]

  [ it would be better if ... ]

  [ this is a kludge and it should be done instead like ... ]

did nobody read what andrew wrote and what JOQ pointed out?

after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

--p

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Nick Piggin wrote:
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
What happened to the RT rlimit code from Chris?
I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.
I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.
So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this "wholly self-contained" feature turned on by default next
year, at which point the "containment" will be nil and whatever warts
it has will be with us forever.
The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.
Personally, I think that the best approach to solving this problem is 
from the privileges aspect.  The ability to grant privileges to only set 
RT policy is just an example of a general need for granting limited 
privileges to a program and/or a user.  So a solution that involved a 
mechanism for granting a specified subset of root privileges to 
specified users when running specified programs would have wider 
application.

My limited understanding of SELinux (which may be mistaken) is that it 
provides a basic framework for this level of privilege control and 
perhaps the solution lies there.

Peter
--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
> On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> > * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > > What happened to the RT rlimit code from Chris?
> > 
> > I still have it, but I had the impression Ingo didn't like it as a long
> > term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> > patch is wholly self-contained.
> 
> I think it's important to recognize that we're trying to address an
> issue that has a much wider potential audience than pro audio users,
> and not very far off - what is high end audio performance today will be
> expected desktop performance next year.
> 
> So I think it's critical that we find solution that's appropriate for
> _every single box_, because realistically vendors are going to ship
> with this "wholly self-contained" feature turned on by default next
> year, at which point the "containment" will be nil and whatever warts
> it has will be with us forever.
> 
> The rlimit stuff is not perfect, but it's a much better fit for the
> UNIX model generally, which is a fairly big win. Having it in the
> system unconditionally doesn't trigger the gag reflex in quite the
> same way as the LSM approach.
> 

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.


http://mobile.yahoo.com.au - Yahoo! Mobile

- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
> * Matt Mackall ([EMAIL PROTECTED]) wrote:
> > What happened to the RT rlimit code from Chris?
> 
> I still have it, but I had the impression Ingo didn't like it as a long
> term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> patch is wholly self-contained.

I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.

So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this "wholly self-contained" feature turned on by default next
year, at which point the "containment" will be nil and whatever warts
it has will be with us forever.

The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Chris Wright

* Matt Mackall ([EMAIL PROTECTED]) wrote:
> What happened to the RT rlimit code from Chris?

I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, Feb 10, 2005 at 02:51:44PM -0600, Jack O'Quin wrote:
> [direct reply bounced, resending via gmail]
> 
> Andrew Morton <[EMAIL PROTECTED]> writes:
> 
> > Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > > > 
> > > > 
> > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio 
> > > > guys.
> > > >   It seems that nothing else is going to come along and this is 
> > > > completely
> > > >   encapsulated.
> > > 
> > > Even if we accept a module that grants capabilities to groups this
> > > isn't fine yet because it only supports two specific capabilities
> > > (and even those two in different ways!) instead of adding generic
> > > support to bind capabilities to groups.
> > 
> > I'm sure that got discussed somewhere in the 1000 emails which flew past
> > last time.  Jack?
> 
> [adding cc: for the main discussion participants]
> 
> Most people felt that a more general capabilities module would be nice
> to have.  But, no one offered any code, or volunteered to work on it.

What happened to the RT rlimit code from Chris?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

> > Without the aty128fb and radeonfb updates, current 2.6.11 is a
> > regression on pmac as it breaks sleep support on previously working
> > laptops.
> 
> Is that worse than the risk of the large patch?

Well, it used to work upstream fine for some time now... The large patch
isn't risky imho, at least in the latest version I sent you. The bulk of
the changes are just code to re-initialize new chip that isn't executed
at all on earlier models. The main radeonfb code changes very little. I
haven't had a failure report with the latest patch yet.

> > If you don't intend to get at least
> > try_to_acquire_console_sem() and aty128fb fix in, in which case i can
> > send you a minimal radeonfb patch, then I'll have to make another patch
> > for 2.6.11 that reverts some of the arch changes to re-enable sleep on
> > those machines.
> 
> Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
> the patches by name - it helps avoid mistakes.

Ahem ... not that badly broken on releases, I've been careful enough
that at least, powerbook sleep worked fine for some time now.
 
> These?
> 
> add-try_acquire_console_sem.patch
> update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch

Those 2 first at least yes

> radeonfb-update.patch
> radeonfb-build-fix.patch

And either the above, or I can do a minimal patch on radeonfb just
restoring sleep on earlier models (adding the pmac_feature call to
notify the arch code that we can wakeup the chip) if you don't want to
merge the bigger update.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Adrian Bunk

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
>...
> - Various other stuff.  If anyone has a patch in here which they think
>   should be in 2.6.11, please let me know.  I'm intending to merge the
>   following into 2.6.11:
> 
>   alpha-add-missing-dma_mapping_error.patch
>   fix-compat-shmget-overflow.patch
>   fix-shmget-for-ppc64-s390-64-sparc64.patch
>   binfmt_elf-clearing-bss-may-fail.patch
>   qlogic-warning-fixes.patch
>   oprofile-exittext-referenced-in-inittext.patch
>   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
>   oprofile-arm-xscale1-pmu-support-fix.patch
>...

As described in the patch description, I'd like to see 
mark-the-mcd-cdrom-driver-as-broken.patch in 2.6.11 .

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > 
> > 
> > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> >   It seems that nothing else is going to come along and this is completely
> >   encapsulated.
> > 
> > - Various other stuff.  If anyone has a patch in here which they think
> >   should be in 2.6.11, please let me know.  I'm intending to merge the
> >   following into 2.6.11:
> > 
> > alpha-add-missing-dma_mapping_error.patch
> > fix-compat-shmget-overflow.patch
> > fix-shmget-for-ppc64-s390-64-sparc64.patch
> > binfmt_elf-clearing-bss-may-fail.patch
> > qlogic-warning-fixes.patch
> > oprofile-exittext-referenced-in-inittext.patch
> > force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
> > oprofile-arm-xscale1-pmu-support-fix.patch
> 
> Without the aty128fb and radeonfb updates, current 2.6.11 is a
> regression on pmac as it breaks sleep support on previously working
> laptops.

Is that worse than the risk of the large patch?

> If you don't intend to get at least
> try_to_acquire_console_sem() and aty128fb fix in, in which case i can
> send you a minimal radeonfb patch, then I'll have to make another patch
> for 2.6.11 that reverts some of the arch changes to re-enable sleep on
> those machines.

Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
the patches by name - it helps avoid mistakes.

These?

add-try_acquire_console_sem.patch
update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
radeonfb-update.patch
radeonfb-build-fix.patch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> 
> 
> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>   It seems that nothing else is going to come along and this is completely
>   encapsulated.
> 
> - Various other stuff.  If anyone has a patch in here which they think
>   should be in 2.6.11, please let me know.  I'm intending to merge the
>   following into 2.6.11:
> 
>   alpha-add-missing-dma_mapping_error.patch
>   fix-compat-shmget-overflow.patch
>   fix-shmget-for-ppc64-s390-64-sparc64.patch
>   binfmt_elf-clearing-bss-may-fail.patch
>   qlogic-warning-fixes.patch
>   oprofile-exittext-referenced-in-inittext.patch
>   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
>   oprofile-arm-xscale1-pmu-support-fix.patch

Without the aty128fb and radeonfb updates, current 2.6.11 is a
regression on pmac as it breaks sleep support on previously working
laptops. If you don't intend to get at least
try_to_acquire_console_sem() and aty128fb fix in, in which case i can
send you a minimal radeonfb patch, then I'll have to make another patch
for 2.6.11 that reverts some of the arch changes to re-enable sleep on
those machines.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Corey Minyard

Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
 It seems that nothing else is going to come along and this is completely
 encapsulated.
- Various other stuff.  If anyone has a patch in here which they think
 should be in 2.6.11, please let me know.  I'm intending to merge the
 following into 2.6.11:
alpha-add-missing-dma_mapping_error.patch
fix-compat-shmget-overflow.patch
fix-shmget-for-ppc64-s390-64-sparc64.patch
binfmt_elf-clearing-bss-may-fail.patch
qlogic-warning-fixes.patch
oprofile-exittext-referenced-in-inittext.patch
force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
oprofile-arm-xscale1-pmu-support-fix.patch
 

The following one should probably go in:
+update-to-ipmi-driver-to-support-old-dmi-spec.patch
 

Systems with old data will not work correctly without it.  There seems 
to be a few of them out there.

-Corey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Jack O'Quin

[direct reply bounced, resending via gmail]

Andrew Morton <[EMAIL PROTECTED]> writes:

> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > > 
> > > 
> > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio 
> > > guys.
> > >   It seems that nothing else is going to come along and this is completely
> > >   encapsulated.
> > 
> > Even if we accept a module that grants capabilities to groups this
> > isn't fine yet because it only supports two specific capabilities
> > (and even those two in different ways!) instead of adding generic
> > support to bind capabilities to groups.
> 
> I'm sure that got discussed somewhere in the 1000 emails which flew past
> last time.  Jack?

[adding cc: for the main discussion participants]

Most people felt that a more general capabilities module would be nice
to have.  But, no one offered any code, or volunteered to work on it.

I have no objection to that approach, but am not willing or able to do
it myself.  My opinion is that expanding the scope of the LSM would
significantly increase its security risk.  That job needs to be done
very carefully, by someone with a deep understanding of the kernel's
internal use of capabilities.

Perhaps, Christoph's suggestion could become part of a more general
module, which might replace the RT-LSM in the 2.8 timeframe.  Our LSM
is a modest solution aimed at solving the immediate needs of audio
developers and users with minimal impact on kernel security or
correctness.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> > 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> > 
> > 
> > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
> >   It seems that nothing else is going to come along and this is completely
> >   encapsulated.
> 
> Even if we accept a module that grants capabilities to groups this isn't fine
> yet because it only supports two specific capabilities (and even those two in
> different ways!) instead of adding generic support to bind capabilities to
> groups.

I'm sure that got discussed somewhere in the 1000 emails which flew past
last time.  Jack?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Christoph Hellwig

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
> 
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
> 
> 
> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
>   It seems that nothing else is going to come along and this is completely
>   encapsulated.

Even if we accept a module that grants capabilities to groups this isn't fine
yet because it only supports two specific capabilities (and even those two in
different ways!) instead of adding generic support to bind capabilities to
groups.

More comments on the actual code:

+#include 
+#include 
+
+#define RT_LSM "Realtime LSM " /* syslog module name prefix */
+#define RT_ERR "Realtime: "/* syslog error message prefix */

+#include 
+MODULE_INFO(vermagic,VERMAGIC_STRING);

This doesn't belong into a module.

+#define MY_NAME __stringify(KBUILD_MODNAME)

Please use normal prefix.  A module shouldn't behave differently depending on
what name you compile it as.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Christoph Hellwig

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
 
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
 
 
 - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
   It seems that nothing else is going to come along and this is completely
   encapsulated.

Even if we accept a module that grants capabilities to groups this isn't fine
yet because it only supports two specific capabilities (and even those two in
different ways!) instead of adding generic support to bind capabilities to
groups.

More comments on the actual code:


+#include linux/module.h
+#include linux/security.h
+
+#define RT_LSM Realtime LSM  /* syslog module name prefix */
+#define RT_ERR Realtime: /* syslog error message prefix */

+#include linux/vermagic.h
+MODULE_INFO(vermagic,VERMAGIC_STRING);

This doesn't belong into a module.

+#define MY_NAME __stringify(KBUILD_MODNAME)

Please use normal prefix.  A module shouldn't behave differently depending on
what name you compile it as.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Christoph Hellwig [EMAIL PROTECTED] wrote:

 On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
  
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
  
  
  - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
It seems that nothing else is going to come along and this is completely
encapsulated.
 
 Even if we accept a module that grants capabilities to groups this isn't fine
 yet because it only supports two specific capabilities (and even those two in
 different ways!) instead of adding generic support to bind capabilities to
 groups.

I'm sure that got discussed somewhere in the 1000 emails which flew past
last time.  Jack?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Jack O'Quin

[direct reply bounced, resending via gmail]

Andrew Morton [EMAIL PROTECTED] writes:

Christoph Hellwig [EMAIL PROTECTED] wrote:

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/

- Added the mlock and !SCHED_OTHER Linux Security Module for the audio
guys.
It seems that nothing else is going to come along and this is completely
encapsulated.

Even if we accept a module that grants capabilities to groups this
isn't fine yet because it only supports two specific capabilities
(and even those two in different ways!) instead of adding generic
support to bind capabilities to groups.

I'm sure that got discussed somewhere in the 1000 emails which flew past
last time. Jack?

[adding cc: for the main discussion participants]

Most people felt that a more general capabilities module would be nice
to have. But, no one offered any code, or volunteered to work on it.

I have no objection to that approach, but am not willing or able to do
it myself. My opinion is that expanding the scope of the LSM would
significantly increase its security risk. That job needs to be done
very carefully, by someone with a deep understanding of the kernel's
internal use of capabilities.

Perhaps, Christoph's suggestion could become part of a more general
module, which might replace the RT-LSM in the 2.8 timeframe. Our LSM
is a modest solution aimed at solving the immediate needs of audio
developers and users with minimal impact on kernel security or
correctness.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Corey Minyard

Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
- Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
 It seems that nothing else is going to come along and this is completely
 encapsulated.
- Various other stuff.  If anyone has a patch in here which they think
 should be in 2.6.11, please let me know.  I'm intending to merge the
 following into 2.6.11:
alpha-add-missing-dma_mapping_error.patch
fix-compat-shmget-overflow.patch
fix-shmget-for-ppc64-s390-64-sparc64.patch
binfmt_elf-clearing-bss-may-fail.patch
qlogic-warning-fixes.patch
oprofile-exittext-referenced-in-inittext.patch
force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
oprofile-arm-xscale1-pmu-support-fix.patch
 

The following one should probably go in:
+update-to-ipmi-driver-to-support-old-dmi-spec.patch
 

Systems with old data will not work correctly without it.  There seems 
to be a few of them out there.

-Corey
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
 
 
 - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
   It seems that nothing else is going to come along and this is completely
   encapsulated.
 
 - Various other stuff.  If anyone has a patch in here which they think
   should be in 2.6.11, please let me know.  I'm intending to merge the
   following into 2.6.11:
 
   alpha-add-missing-dma_mapping_error.patch
   fix-compat-shmget-overflow.patch
   fix-shmget-for-ppc64-s390-64-sparc64.patch
   binfmt_elf-clearing-bss-may-fail.patch
   qlogic-warning-fixes.patch
   oprofile-exittext-referenced-in-inittext.patch
   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
   oprofile-arm-xscale1-pmu-support-fix.patch

Without the aty128fb and radeonfb updates, current 2.6.11 is a
regression on pmac as it breaks sleep support on previously working
laptops. If you don't intend to get at least
try_to_acquire_console_sem() and aty128fb fix in, in which case i can
send you a minimal radeonfb patch, then I'll have to make another patch
for 2.6.11 that reverts some of the arch changes to re-enable sleep on
those machines.

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
  
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/
  
  
  - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.
It seems that nothing else is going to come along and this is completely
encapsulated.
  
  - Various other stuff.  If anyone has a patch in here which they think
should be in 2.6.11, please let me know.  I'm intending to merge the
following into 2.6.11:
  
  alpha-add-missing-dma_mapping_error.patch
  fix-compat-shmget-overflow.patch
  fix-shmget-for-ppc64-s390-64-sparc64.patch
  binfmt_elf-clearing-bss-may-fail.patch
  qlogic-warning-fixes.patch
  oprofile-exittext-referenced-in-inittext.patch
  force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
  oprofile-arm-xscale1-pmu-support-fix.patch
 
 Without the aty128fb and radeonfb updates, current 2.6.11 is a
 regression on pmac as it breaks sleep support on previously working
 laptops.

Is that worse than the risk of the large patch?

 If you don't intend to get at least
 try_to_acquire_console_sem() and aty128fb fix in, in which case i can
 send you a minimal radeonfb patch, then I'll have to make another patch
 for 2.6.11 that reverts some of the arch changes to re-enable sleep on
 those machines.

Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
the patches by name - it helps avoid mistakes.

These?

add-try_acquire_console_sem.patch
update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
radeonfb-update.patch
radeonfb-build-fix.patch

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Adrian Bunk

On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:
...
 - Various other stuff.  If anyone has a patch in here which they think
   should be in 2.6.11, please let me know.  I'm intending to merge the
   following into 2.6.11:
 
   alpha-add-missing-dma_mapping_error.patch
   fix-compat-shmget-overflow.patch
   fix-shmget-for-ppc64-s390-64-sparc64.patch
   binfmt_elf-clearing-bss-may-fail.patch
   qlogic-warning-fixes.patch
   oprofile-exittext-referenced-in-inittext.patch
   force-read-implies-exec-for-all-32bit-processes-in-x86-64.patch
   oprofile-arm-xscale1-pmu-support-fix.patch
...

As described in the patch description, I'd like to see 
mark-the-mcd-cdrom-driver-as-broken.patch in 2.6.11 .

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

  Without the aty128fb and radeonfb updates, current 2.6.11 is a
  regression on pmac as it breaks sleep support on previously working
  laptops.
 
 Is that worse than the risk of the large patch?

Well, it used to work upstream fine for some time now... The large patch
isn't risky imho, at least in the latest version I sent you. The bulk of
the changes are just code to re-initialize new chip that isn't executed
at all on earlier models. The main radeonfb code changes very little. I
haven't had a failure report with the latest patch yet.

  If you don't intend to get at least
  try_to_acquire_console_sem() and aty128fb fix in, in which case i can
  send you a minimal radeonfb patch, then I'll have to make another patch
  for 2.6.11 that reverts some of the arch changes to re-enable sleep on
  those machines.
 
 Ho hum.  PM and fbdev are regularly broken anyway.  Please always identify
 the patches by name - it helps avoid mistakes.

Ahem ... not that badly broken on releases, I've been careful enough
that at least, powerbook sleep worked fine for some time now.
 
 These?
 
 add-try_acquire_console_sem.patch
 update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch

Those 2 first at least yes

 radeonfb-update.patch
 radeonfb-build-fix.patch

And either the above, or I can do a minimal patch on radeonfb just
restoring sleep on earlier models (adding the pmac_feature call to
notify the arch code that we can wakeup the chip) if you don't want to
merge the bigger update.

Ben.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, Feb 10, 2005 at 02:51:44PM -0600, Jack O'Quin wrote:
 [direct reply bounced, resending via gmail]
 
 Andrew Morton [EMAIL PROTECTED] writes:
 
  Christoph Hellwig [EMAIL PROTECTED] wrote:
  
   On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/


- Added the mlock and !SCHED_OTHER Linux Security Module for the audio 
guys.
  It seems that nothing else is going to come along and this is 
completely
  encapsulated.
   
   Even if we accept a module that grants capabilities to groups this
   isn't fine yet because it only supports two specific capabilities
   (and even those two in different ways!) instead of adding generic
   support to bind capabilities to groups.
  
  I'm sure that got discussed somewhere in the 1000 emails which flew past
  last time.  Jack?
 
 [adding cc: for the main discussion participants]
 
 Most people felt that a more general capabilities module would be nice
 to have.  But, no one offered any code, or volunteered to work on it.

What happened to the RT rlimit code from Chris?

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Chris Wright

* Matt Mackall ([EMAIL PROTECTED]) wrote:
 What happened to the RT rlimit code from Chris?

I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
 * Matt Mackall ([EMAIL PROTECTED]) wrote:
  What happened to the RT rlimit code from Chris?
 
 I still have it, but I had the impression Ingo didn't like it as a long
 term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
 patch is wholly self-contained.

I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.

So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this wholly self-contained feature turned on by default next
year, at which point the containment will be nil and whatever warts
it has will be with us forever.

The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
 On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
  * Matt Mackall ([EMAIL PROTECTED]) wrote:
   What happened to the RT rlimit code from Chris?
  
  I still have it, but I had the impression Ingo didn't like it as a long
  term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
  patch is wholly self-contained.
 
 I think it's important to recognize that we're trying to address an
 issue that has a much wider potential audience than pro audio users,
 and not very far off - what is high end audio performance today will be
 expected desktop performance next year.
 
 So I think it's critical that we find solution that's appropriate for
 _every single box_, because realistically vendors are going to ship
 with this wholly self-contained feature turned on by default next
 year, at which point the containment will be nil and whatever warts
 it has will be with us forever.
 
 The rlimit stuff is not perfect, but it's a much better fit for the
 UNIX model generally, which is a fairly big win. Having it in the
 system unconditionally doesn't trigger the gag reflex in quite the
 same way as the LSM approach.
 

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.


http://mobile.yahoo.com.au - Yahoo! Mobile

- Check  compose your email via SMS on your Telstra or Vodafone mobile.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Nick Piggin wrote:
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote:
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote:
* Matt Mackall ([EMAIL PROTECTED]) wrote:
What happened to the RT rlimit code from Chris?
I still have it, but I had the impression Ingo didn't like it as a long
term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
patch is wholly self-contained.
I think it's important to recognize that we're trying to address an
issue that has a much wider potential audience than pro audio users,
and not very far off - what is high end audio performance today will be
expected desktop performance next year.
So I think it's critical that we find solution that's appropriate for
_every single box_, because realistically vendors are going to ship
with this wholly self-contained feature turned on by default next
year, at which point the containment will be nil and whatever warts
it has will be with us forever.
The rlimit stuff is not perfect, but it's a much better fit for the
UNIX model generally, which is a fairly big win. Having it in the
system unconditionally doesn't trigger the gag reflex in quite the
same way as the LSM approach.

Without considering the userspace aspect, RT rlimits is the best
implementation I have seen. All others either break RT scheduling
semantics, or don't allow any way for root to maintain control of
the system after giving out RT privileges.
Personally, I think that the best approach to solving this problem is 
from the privileges aspect.  The ability to grant privileges to only set 
RT policy is just an example of a general need for granting limited 
privileges to a program and/or a user.  So a solution that involved a 
mechanism for granting a specified subset of root privileges to 
specified users when running specified programs would have wider 
application.

My limited understanding of SELinux (which may be mistaken) is that it 
provides a basic framework for this level of privilege control and 
perhaps the solution lies there.

Peter
--
Peter Williams   [EMAIL PROTECTED]
Learning, n. The kind of ignorance distinguishing the studious.
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Paul Davis

  [ the best solution is  ]

  [ my preferred solution is ... ]

  [ it would be better if ... ]

  [ this is a kludge and it should be done instead like ... ]

did nobody read what andrew wrote and what JOQ pointed out?

after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

--p

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
   [ the best solution is  ]
 
   [ my preferred solution is ... ]
 
   [ it would be better if ... ]
 
   [ this is a kludge and it should be done instead like ... ]
 
 did nobody read what andrew wrote and what JOQ pointed out?
 
 after weeks of debating this, no other conceptual solution emerged
 that did not have at least as many problems as the RT LSM module, and
 all other proposed solutions were also more invasive of other aspects
 of kernel design and operations than RT LSM is.
 

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.

I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.

Nick




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

Paul Davis wrote:
  [ the best solution is  ]
  [ my preferred solution is ... ]
  [ it would be better if ... ]
  [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.
As I see it, what I said was in support of RT LSM (or at least the 
approach that RT LSM is taking) so why are you attacking me.  I'm on 
your side :-)

Peter
PS I'm withdrawing the unprivileged real time feature from the 
spa_no_frills and zaphod schedulers in the PlugSched patch as a result 
of the discussions on SCHED_ISO and RT rlimits because the discussion 
convinced me that it's the wrong way to go.
--
Peter Williams   [EMAIL PROTECTED]

Learning, n. The kind of ignorance distinguishing the studious.
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2 (compile stats)

2005-02-10 Thread John Cherry

Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

KernelbzImage   bzImage  bzImage  modules  bzImage  modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--- --     
2.6.11-rc3-mm2   14w/0e 0w/0e   192w/0e6w/0e  19w/0e172w/0e
2.6.11-rc3-mm1   13w/10e0w/7e   196w/12e   6w/0e  18w/12e   177w/0e
2.6.11-rc2-mm2   15w/0e 0w/0e   201w/0e6w/0e  18w/0e182w/0e
2.6.11-rc2-mm1   15w/0e 0w/0e   306w/14e   6w/0e  18w/0e294w/0e
2.6.11-rc1-mm2   21w/0e 0w/0e   316w/9e6w/0e  22w/0e294w/0e
2.6.11-rc1-mm1   21w/0e 0w/0e   319w/0e6w/0e  23w/0e298w/0e
2.6.10-mm3   21w/0e 0w/0e   320w/0e6w/0e  23w/0e299w/0e
2.6.10-mm2   21w/0e 0w/0e   440w/0e6w/0e  23w/0e420w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-mm1   12w/0e 0w/0e   414w/0e6w/0e  17w/0e399w/0e
2.6.10-rc3-mm1   12w/0e 0w/0e   414w/0e6w/0e  16w/0e401w/0e
2.6.10-rc2-mm4   15w/0e 1w/7e   421w/0e6w/0e  16w/0e408w/0e
2.6.10-rc2-mm3   15w/0e 0w/0e  1255w/12e  66w/0e  16w/0e   1507w/0e
2.6.10-rc2-mm2   15w/0e 0w/0e  1362w/15e  65w/0e  16w/0e   1612w/2e
2.6.10-rc2-mm1   15w/0e 0w/0e  1405w/11e  65w/0e  16w/0e   1652w/0e
2.6.10-rc1-mm5   16w/0e 0w/0e  1587w/0e   65w/0e  20w/0e   1834w/0e
2.6.10-rc1-mm4   16w/0e 0w/0e  1485w/9e   65w/0e  20w/0e   1732w/0e
(Compiles with gcc 3.2.2)
2.6.10-rc1-mm37w/31e0w/9e   496w/141e  4w/0e   4w/50e   693w/83e
2.6.10-rc1-mm2   16w/1e 1w/1e   529w/1e4w/0e  12w/1e729w/0e
2.6.10-rc1-mm1   16w/1e 1w/1e   592w/1e4w/0e  13w/1e857w/0e
2.6.9-mm1 6w/1e 1w/1e  1761w/15e  65w/0e   9w/0e   2086w/0e
2.6.9-rc4-mm1 5w/0e 0w/0e  1766w/11e  43w/0e   6w/0e   1798w/0e
2.6.9-rc3-mm3 5w/0e 0w/0e  1756w/11e  43w/0e   4w/0e   1786w/0e
2.6.9-rc3-mm210w/0e 4w/9e  1754w/14e  43w/0e   4w/0e   1782w/1e
2.6.9-rc3-mm110w/0e 4w/10e 1768w/0e   43w/0e   4w/0e   1796w/0e
2.6.9-rc2-mm410w/0e 5w/0e  2573w/0e   41w/0e   4w/0e   2600w/0e
2.6.9-rc2-mm310w/0e 5w/0e  2400w/0e   41w/0e   4w/0e   2435w/0e
2.6.9-rc2-mm210w/0e 5w/0e  2919w/0e   41w/0e   4w/0e   2954w/0e
2.6.9-rc2-mm1 0w/0e 2w/0e  3541w/9e   41w/0e   3w/9e   3567w/0e
2.6.9-rc1-mm4 0w/0e 1w/0e55w/0e3w/0e   2w/0e 48w/0e
2.6.9-rc1-mm3 0w/0e 0w/0e55w/13e   3w/0e   1w/0e 49w/1e
2.6.9-rc1-mm2 0w/0e 0w/0e53w/11e   3w/0e   1w/0e 47w/0e
2.6.9-rc1-mm1 0w/0e 0w/0e80w/0e4w/0e   1w/0e 74w/0e
2.6.8.1-mm4   0w/0e 0w/0e78w/0e4w/0e   1w/0e 73w/0e
2.6.8.1-mm3   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm2   0w/96e0w/0e78w/97e   4w/0e   1w/0e 74w/89e
2.6.8.1-mm1   0w/0e 0w/0e78w/0e4w/0e   1w/0e 74w/0e
2.6.8-rc4-mm1 0w/0e 0w/5e81w/0e4w/0e   1w/0e 75w/0e
2.6.8-rc3-mm2 1w/7e 0w/5e82w/8e4w/0e   2w/8e 75w/0e
2.6.8-rc3-mm1 0w/0e 1w/5e81w/9e4w/0e   1w/0e 75w/0e
2.6.8-rc2-mm2 0w/0e 4w/5e87w/9e4w/0e   1w/0e 80w/0e
2.6.8-rc2-mm1 0w/0e 0w/0e83w/9e3w/0e   1w/0e 81w/0e
2.6.8-rc1-mm1 0w/0e 0w/0e88w/9e5w/0e   1w/0e 87w/0e
2.6.7-mm7 0w/0e 0w/0e89w/9e5w/0e   1w/0e 84w/0e
2.6.7-mm6 0w/0e 0w/0e85w/9e5w/0e   1w/0e 80w/0e
2.6.7-mm5 0w/0e 0w/0e92w/0e5w/0e   1w/0e 87w/0e
2.6.7-mm4 0w/0e 0w/0e94w/0e5w/0e   1w/0e 89w/0e
2.6.7-mm3 0w/0e 0w/0e90w/6e5w/0e   1w/0e 86w/0e
2.6.7-mm2 0w/0e 0w/0e   109w/0e7w/0e   1w/0e106w/0e
2.6.7-mm1 0w/0e 5w/0e   108w/0e5w/0e   1w/0e104w/0e
2.6.7-rc3-mm2 0w/0e 5w/0e   105w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc3-mm1 0w/0e 5w/0e   104w/10e   5w/0e   2w/0e100w/2e
2.6.7-rc2-mm2 0w/0e 5w/0e   109w/10e   5w/0e   2w/0e105w/2e
2.6.7-rc2-mm1 0w/0e12w/0e   158w/13e   5w/0e   3w/0e153w/4e
2.6.7-rc1-mm1 0w/0e 6w/0e   108w/0e

Re: 2.6.11-rc3-mm2

Nick Piggin wrote:
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote:
 [ the best solution is  ]
 [ my preferred solution is ... ]
 [ it would be better if ... ]
 [ this is a kludge and it should be done instead like ... ]
did nobody read what andrew wrote and what JOQ pointed out?
after weeks of debating this, no other conceptual solution emerged
that did not have at least as many problems as the RT LSM module, and
all other proposed solutions were also more invasive of other aspects
of kernel design and operations than RT LSM is.

Sure, it is quick and easy. Suits some. At least I do prefer
this to altering the semantics of realtime scheduling.
I can't say much about it because I'm not putting my hand up to
do anything. Just mentioning that rlimit would be better if not
for the userspace side of the equation. I think most were already
agreed on that point anyway though.
I think that the rlimits are a good idea in themselves but not as a 
solution to this problem.  I.e. having a RT CPU rate rlimit should not 
be a sufficient (or necessary for that matter) condition to change 
policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
possibility of lock out.  (But I guess even that is a violation of RT 
semantics?)

Peter
PS Zaphod's per task hard/soft CPU rate caps (which are the equivalent 
of an rlimit on CPU usage rate) are only enforced for SCHED_NORMAL tasks 
and should not (therefore) effect RT semantics.
--
Peter Williams   [EMAIL PROTECTED]

Learning, n. The kind of ignorance distinguishing the studious.
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2

On Fri, 2005-02-11 at 17:34 +1100, Peter Williams wrote:
 Nick Piggin wrote:

  I can't say much about it because I'm not putting my hand up to
  do anything. Just mentioning that rlimit would be better if not
  for the userspace side of the equation. I think most were already
  agreed on that point anyway though.
 
 I think that the rlimits are a good idea in themselves but not as a 
 solution to this problem.  I.e. having a RT CPU rate rlimit should not 
 be a sufficient (or necessary for that matter) condition to change 
 policy to SCHED_OTHER or SCHED_RR but could still be used to limit the 
 possibility of lock out.

Ah well that may be a good way to do it indeed. As I said, I
don't know much about privileges etc.

But I just want to be clear that I'm not trying to stop RT-LSM
going in (if only because I don't care one way or the other
about it).

   (But I guess even that is a violation of RT 
 semantics?)
 

I'd have to re-read the standard, but it may not be. For example,
a compliant system advertises the minimum and maximum priority
levels available - you may be able to adjust these based on what
the rlimit is set to. On the other hand, yes it may violate the
stanards.

Nick




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3-mm2