From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965306AbbEMNJV (ORCPT ); Wed, 13 May 2015 09:09:21 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:45757 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964874AbbEMNJT (ORCPT ); Wed, 13 May 2015 09:09:19 -0400 Date: Wed, 13 May 2015 06:09:12 -0700 From: "Paul E. McKenney" To: josh@joshtriplett.org Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com, stable@vger.kernel.org Subject: Re: [PATCH tip/core/rcu 3/3] rcu: Correctly handle non-empty Tiny RCU callback list with none ready Message-ID: <20150513130912.GY6776@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150512224855.GA4776@linux.vnet.ibm.com> <1431470953-4910-1-git-send-email-paulmck@linux.vnet.ibm.com> <1431470953-4910-3-git-send-email-paulmck@linux.vnet.ibm.com> <20150513005821.GD14292@cloud> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150513005821.GD14292@cloud> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15051313-0029-0000-0000-000009BDC84E Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 12, 2015 at 05:58:21PM -0700, josh@joshtriplett.org wrote: > On Tue, May 12, 2015 at 03:49:13PM -0700, Paul E. McKenney wrote: > > From: "Paul E. McKenney" > > > > If, at the time __rcu_process_callbacks() is invoked, there are callbacks > > in Tiny RCU's callback list, but none of them are ready to be invoked, > > the current list-management code will knit the non-ready callbacks out > > of the list. This can result in hangs and possibly worse. This commit > > therefore inserts a check for there being no callbacks that can be > > invoked immediately. > > > > This bug is unlikely to occur -- you have to get a new callback between > > the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to > > __rcu_process_callbacks(). It was detected by the addition of RCU-bh > > testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's > > mutation testing. Although this bug was made much more likely by > > 915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this > > did not cause the bug, but rather made it much more probable. That > > said, it takes more than 40 hours of rcutorture testing, on average, > > for this bug to appear, so this fix cannot be considered an emergency. > > > > Signed-off-by: Paul E. McKenney > > Cc: > > Ouch, subtle. Indeed! A bit of a cautionary tale for those who believe that bugs occur only in concurrent code. Of course, they could respond that this bug was in fact due to a concurrent interrupt handler. Still, I must confess that this bug is a bit embarrassing. ;-) > Reviewed-by: Josh Triplett Thank you, applied! Thanx, Paul > > kernel/rcu/tiny.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c > > index a501b4ab9b1c..591af0cb7b9f 100644 > > --- a/kernel/rcu/tiny.c > > +++ b/kernel/rcu/tiny.c > > @@ -137,6 +137,11 @@ static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp) > > > > /* Move the ready-to-invoke callbacks to a local list. */ > > local_irq_save(flags); > > + if (rcp->donetail == &rcp->rcucblist) { > > + /* No callbacks ready, so just leave. */ > > + local_irq_restore(flags); > > + return; > > + } > > RCU_TRACE(trace_rcu_batch_start(rcp->name, 0, rcp->qlen, -1)); > > list = rcp->rcucblist; > > rcp->rcucblist = *rcp->donetail; > > -- > > 1.8.1.5 > > >