diff options
author | Andreas Steinmetz <ast@domdv.de> | 2005-07-23 13:42:04 +0200 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-07-26 15:30:51 -0700 |
commit | 18586e721636527cb5177467fb17e2350615978a (patch) | |
tree | 96d34b10d000fa8b1df16ae8f4c73761013371b5 /fs/jbd/Makefile | |
parent | fc00a6274b786f6863b32c79ff6f92aa0960b789 (diff) | |
download | kernel_samsung_smdk4412-18586e721636527cb5177467fb17e2350615978a.tar.gz kernel_samsung_smdk4412-18586e721636527cb5177467fb17e2350615978a.tar.bz2 kernel_samsung_smdk4412-18586e721636527cb5177467fb17e2350615978a.zip |
[PATCH] Fix RLIMIT_RTPRIO breakage
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use
SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the
RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by
audio users.
Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt
from sched_setscheduler below:
/*
* Allow unprivileged RT tasks to decrease priority:
*/
if (!capable(CAP_SYS_NICE)) {
/* can't change policy */
if (policy != p->policy)
return -EPERM;
After the above unconditional test which causes sched_setscheduler to
fail with no regard to the RLIMIT_RTPRIO value the following check is made:
/* can't increase priority */
if (policy != SCHED_NORMAL &&
param->sched_priority > p->rt_priority &&
param->sched_priority >
p->signal->rlim[RLIMIT_RTPRIO].rlim_cur)
return -EPERM;
Thus I do believe that the RLIMIT_RTPRIO value must be taken into
account for the policy check, especially as the RLIMIT_RTPRIO limit is
of no use without this change.
The attached patch fixes this problem.
Signed-off-by: Andreas Steinmetz <ast@domdv.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/jbd/Makefile')
0 files changed, 0 insertions, 0 deletions