From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754061AbcALUwI (ORCPT ); Tue, 12 Jan 2016 15:52:08 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:44548 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752235AbcALUwF (ORCPT ); Tue, 12 Jan 2016 15:52:05 -0500 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 12 Jan 2016 12:52:00 -0800 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Sasha Levin , Thomas Gleixner , LKML Subject: Re: timers: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected Message-ID: <20160112205200.GJ3818@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <56955C0F.1090005@oracle.com> <20160112201856.GD6375@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160112201856.GD6375@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16011220-8236-0000-0000-0000151F75F0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2016 at 09:18:56PM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 03:03:27PM -0500, Sasha Levin wrote: > > [ 3408.703754] Call Trace: > > > [ 3408.733192] rcu_read_unlock_special (kernel/rcu/tree_plugin.h:503) > > [ 3408.735155] __rcu_read_unlock (kernel/rcu/update.c:223) > > [ 3408.736090] __lock_timer (include/linux/rcupdate.h:495 include/linux/rcupdate.h:930 kernel/time/posix-timers.c:709) > > I'm thinking this is one of those magic preemptible RCU bits.. Hmmm... Looking back at Sasha's original email, RCU doesn't have much choice about making ->wait_lock HARDIRQ-irq-unsafe, since it acquires it via a call to rt_mutex_lock(), which cannot be invoked with irqs disabled. In fact, it seems a bit odd to acquire something named ->wait_lock with irqs disabled. That said... > --- > kernel/time/posix-timers.c | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c > index 31d11ac9fa47..09e28733e725 100644 > --- a/kernel/time/posix-timers.c > +++ b/kernel/time/posix-timers.c > @@ -701,17 +701,25 @@ static struct k_itimer *__lock_timer(timer_t timer_id, unsigned long *flags) > if ((unsigned long long)timer_id > INT_MAX) > return NULL; > > + /* > + * One of the few rules of preemptible RCU is that one cannot do > + * rcu_read_unlock() while holding a scheduler (or nested) lock when > + * part of the read side critical section was irqs-enabled -- see > + * rcu_read_unlock_special(). > + */ > + local_irq_safe(*flags); > rcu_read_lock(); > timr = posix_timer_by_id(timer_id); > if (timr) { > - spin_lock_irqsave(&timr->it_lock, *flags); > + spin_lock(&timr->it_lock); > if (timr->it_signal == current->signal) { > rcu_read_unlock(); If ->it_lock is ever acquired while one of the rq or pi locks was held, Peter's patch is needed. It is just that I am not seeing what I would expect to see in Sasha's lockdep splat if that were the case. Thanx, Paul > return timr; > } > - spin_unlock_irqrestore(&timr->it_lock, *flags); > + spin_unlock(&timr->it_lock); > } > rcu_read_unlock(); > + local_irq_restore(*flags); > > return NULL; > } >