[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200423092620.GR20730@hirez.programming.kicks-ass.net>
Date: Thu, 23 Apr 2020 11:26:20 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Hillf Danton <hdanton@...a.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Mike Galbraith <efault@....de>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] sched: make p->prio independent of p->mm
On Thu, Apr 23, 2020 at 12:01:28PM +0800, Hillf Danton wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4796,13 +4796,19 @@ recheck:
> return -EINVAL;
>
> /*
> - * Valid priorities for SCHED_FIFO and SCHED_RR are
> - * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_NORMAL,
> - * SCHED_BATCH and SCHED_IDLE is 0.
> + * The MAX_USER_RT_PRIO value allows the actual maximum
> + * RT priority to be separate from the value exported to
> + * user-space. This allows kernel threads to set their
> + * priority to a value higher than any user task.
> */
> - if ((p->mm && attr->sched_priority > MAX_USER_RT_PRIO-1) ||
> - (!p->mm && attr->sched_priority > MAX_RT_PRIO-1))
> - return -EINVAL;
> + if (p->flags & PF_KTHREAD) {
> + if (attr->sched_priority > MAX_RT_PRIO - 1)
> + return -EINVAL;
> + } else {
> + if (attr->sched_priority > MAX_USER_RT_PRIO - 1)
> + return -EINVAL;
> + }
> +
Arguably we can do away with the check entirely, MAX_RT_PRIO ==
MAX_USER_RT_PRIO.
Powered by blists - more mailing lists