Messages in this thread | | | Date | Tue, 11 Jan 2005 13:42:51 -0800 | From | Chris Wright <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
* Matt Mackall (mpm@selenic.com) wrote: > On Tue, Jan 11, 2005 at 12:47:07PM -0800, Chris Wright wrote: > > Guys, could we please bring this back to a useful discussion. None of > > you have commented on whether the rlimits for priority are useful. As I > > said before, I've no real problem with the module as it stands since it's > > tiny, quite contained, and does something people need. But I agree it'd > > be better to find something that's workable as long term solution. > > I almost like it. I don't like that it exposes the internal scheduler > priorities directly (-tiny in fact has options to change these!). So > perhaps some thought could be given to either stratifying it a bit > more (>2000 for SCHED_FIFO, >1000 for SCHED_RR, then SCHED_OTHER) or > separate limits for the different scheduling disciplines.
Yeah, I don't like that either (thought I mentioned it in earliest patch). I thought about the method you mentioned, but didn't like it much better. I also suggested using 0 == default, 1 == can nice down, 2 == can set RT prio. Utz suggests just splitting nice limit from rt limit.
> But I'm also still not convinced this policy can't be most flexibly > handled by a setuid helper together with the mlock rlimit.
Wait, why can't it be done with (to date fictitious) pam_prio, which simply calls sched_setscheduler? It's already privileged while it's doing these things...
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |