2.6.13rc3: RLIMIT_RTPRIO broken

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:

Quoted 5 lines · Andreas Steinmetz

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.

Quoted 2 lines

Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt from sched_setscheduler below:

Please provide the Signed-Off-By line. Also I have cc'ed Matt Mackall, the original author of the patch.

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. I would appreciate it if the fix would make it into 2.6.13.

[back from KS/OLS]

indeed. The effect of the bug is that RLIMIT_RTPRIO is completely non-functional in 2.6.12.

Acked-by Ingo Molnar <[email protected]>

2005/7/26, Ingo Molnar <[email protected]>:
[...]

Quoted 2 lines

[back from KS/OLS]

Quoted 4 lines

indeed. The effect of the bug is that RLIMIT_RTPRIO is completely non-functional in 2.6.12.

Acked-by Ingo Molnar <[email protected]>

Ingo, Lee, Andreas,
the patch seems to be quite simple and is a fix for a regression. Is anybody going to FW it to the stable team ?

i'd not put it into stable just yet - the fact that it has not been tested in 2.6.12 _at all_ up until very recently means there's little QA feedback. Yes, it's simple, but it also triggers something we never did before. 2.6.13 ought to be released soon, that should be good enough.