summaryrefslogtreecommitdiffstats
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorAndreas Steinmetz2005-07-23 13:42:04 +0200
committerLinus Torvalds2005-07-27 00:30:51 +0200
commit18586e721636527cb5177467fb17e2350615978a (patch)
tree96d34b10d000fa8b1df16ae8f4c73761013371b5 /MAINTAINERS
parentMerge master.kernel.org:/home/rmk/linux-2.6-arm (diff)
downloadkernel-qcow2-linux-18586e721636527cb5177467fb17e2350615978a.tar.gz
kernel-qcow2-linux-18586e721636527cb5177467fb17e2350615978a.tar.xz
kernel-qcow2-linux-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 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions