linux-kernel - Re: [PATCH] sched: Do not bug in __sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 May 2017 18:55:20 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Laurent Dufour <ldufour@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...l.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...e.hu>,
        Francesco Dolcini <francesco@...cini.it>
Subject: Re: [PATCH] sched: Do not bug in __sched_setscheduler() when pi is
 not used


Peter,

I've just been pinged by someone that triggered this bug again. Can you
take this patch and it probably should be marked for stable too.

-- Steve


On Thu, 9 Mar 2017 10:18:42 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
> 
> 
> When priority inheritance was added back in 2.6.18 to sched_setscheduler, it
> added a path to taking an rt-mutex wait_lock, which is not IRQ safe. As PI
> is not a common occurrence, lockdep will likely never trigger if
> sched_setscheduler was called from interrupt context. A BUG_ON() was added
> to trigger if __sched_setscheduler() was ever called from interrupt context
> because there was a possibility to take the wait_lock.
> 
> Today the wait_lock is irq safe, but the path to taking it in
> sched_setscheduler() is the same as the path to taking it from normal
> context. The wait_lock is taken with raw_spin_lock_irq() and released with
> raw_spin_unlock_irq() which will indiscriminately enable interrupts,
> which would be bad in interrupt context.
> 
> The problem is that normalize_rt_tasks, which is called by triggering the
> sysrq nice-all-RT-tasks was changed to call __sched_setscheduler(), and this
> is done from interrupt context!
> 
> Now __sched_setscheduler() takes a "pi" parameter that is used to know if
> the priority inheritance should be called or not. As the BUG_ON() only cares
> about calling the PI code, it should only bug if called from interrupt
> context with the "pi" parameter set to true.
> 
> Link: http://lkml.kernel.org/r/20170308124654.10e598f2@gandalf.local.home
> 
> Reported-by: Laurent Dufour <ldufour@...ux.vnet.ibm.com>
> Tested-by: Laurent Dufour <ldufour@...ux.vnet.ibm.com>
> Fixes: dbc7f069b93a ("sched: Use replace normalize_task() with __sched_setscheduler()")
> Cc: Andrew Morton <akpm@...l.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: stable@...r.kernel.org
> Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
> ---
>  kernel/sched/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 3b31fc0..7292fa9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4129,8 +4129,8 @@ static int __sched_setscheduler(struct task_struct *p,
>  	int queue_flags = DEQUEUE_SAVE | DEQUEUE_MOVE;
>  	struct rq *rq;
>  
> -	/* May grab non-irq protected spin_locks: */
> -	BUG_ON(in_interrupt());
> +	/* The pi code expects interrupts enabled */
> +	BUG_ON(pi && in_interrupt());
>  recheck:
>  	/* Double check policy once rq lock held: */
>  	if (policy < 0) {