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/
