From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754052AbdCHRkU (ORCPT ); Wed, 8 Mar 2017 12:40:20 -0500 Received: from mail.kernel.org ([198.145.29.136]:38878 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752986AbdCHRkR (ORCPT ); Wed, 8 Mar 2017 12:40:17 -0500 Date: Wed, 8 Mar 2017 12:40:12 -0500 From: Steven Rostedt To: Laurent Dufour Cc: Andrew Morton , Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , Peter Zijlstra Subject: Re: RFC: SysRq nice-all-RT-tasks is broken Message-ID: <20170308124012.496a75cf@gandalf.local.home> In-Reply-To: <22b0e5fe-2aa1-72de-4d00-29d768d226ca@linux.vnet.ibm.com> References: <20170308115114.4e20fc73@gandalf.local.home> <20170308115758.43b38bc7@gandalf.local.home> <22b0e5fe-2aa1-72de-4d00-29d768d226ca@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Added Peter Update: Laurent noticed that sysrq 'n' (nice-all-RT-tasks) calls __sched_setscheduler() form interrupt context. At the start of that function, there's a BUG_ON(in_interrupt()). The reason for that was due to the rt mutex pi code calling wait_lock. Which was not irq safe. Now it is, but that's not good enough. ] On Wed, 8 Mar 2017 18:03:55 +0100 Laurent Dufour wrote: > On 08/03/2017 17:57, Steven Rostedt wrote: > > On Wed, 8 Mar 2017 11:51:14 -0500 > > Steven Rostedt wrote: > > > > > >> Hmm, that commit was added in 2.6.18, and you're right, a lot has > >> changed since then. Have you tried removing it and running it under > >> lockdep, and see if it triggers any warnings? > > > > I did a little digging, and it appears that its the rt mutex wait lock > > that the comment was referring to. Today that spin lock is irq safe. I > > believe its safe to remove the BUG_ON(). Want me to send a patch? > > Sure, go ahead ;) > Actually, it's still not safe :-/ I just noticed this in the call path: raw_spin_unlock_irq(&task->pi_lock); As well as other raw_spin_unlock_irq()s. Which would enable interrupts regardless of the previous state. One solution is to change all those to irqsave() but that seems to be a big step for something that is rarely done (how many years has it been since 2.6.18?). I wonder if we should just have a special flag sent by that sysrq trigger. Since it is causing all tasks to go "nice" there's no need to do the pi chain walk in __sched_setscheduler(). -- Steve