From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752253Ab2JNXdk (ORCPT ); Sun, 14 Oct 2012 19:33:40 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:53180 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752009Ab2JNXdi (ORCPT ); Sun, 14 Oct 2012 19:33:38 -0400 Date: Sun, 14 Oct 2012 16:32:49 -0700 From: "Paul E. McKenney" To: Ben Hutchings Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, stable@vger.kernel.org, alan@lxorguk.ukuu.org.uk, Becky Bruce , Subodh Nijsure , Paul Walmsley , Greg Kroah-Hartman Subject: Re: [ 097/120] rcu: Fix day-one dyntick-idle stall-warning bug Message-ID: <20121014233249.GB3288@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20121011005825.364610894@linuxfoundation.org> <20121011005844.760264316@linuxfoundation.org> <1350080068.4832.35.camel@deadeye.wl.decadent.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1350080068.4832.35.camel@deadeye.wl.decadent.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12101423-5518-0000-0000-00000870CBD2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 12, 2012 at 11:14:28PM +0100, Ben Hutchings wrote: > On Thu, 2012-10-11 at 10:00 +0900, Greg Kroah-Hartman wrote: > > 3.4-stable review patch. If anyone has any objections, please let me know. > > > > ------------------ > > > > From: "Paul E. McKenney" > > > > commit a10d206ef1a83121ab7430cb196e0376a7145b22 upstream. > [...] > > This commit therefore makes CPUs check more carefully before starting a > > new grace period. This new check relies on an array of tail pointers > > into each CPU's list of callbacks. If the CPU is up to date on which > > grace periods have completed, it checks to see if any callbacks follow > > the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks > > follow the RCU_WAIT_TAIL segment. The reason that this works is that > > the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment > > as soon as the CPU is officially notified that the old grace period > > has ended. > [...] > > --- a/kernel/rcutree.c > > +++ b/kernel/rcutree.c > > @@ -295,7 +295,9 @@ cpu_has_callbacks_ready_to_invoke(struct > > static int > > cpu_needs_another_gp(struct rcu_state *rsp, struct rcu_data *rdp) > > { > > - return *rdp->nxttail[RCU_DONE_TAIL] && !rcu_gp_in_progress(rsp); > > + return *rdp->nxttail[RCU_DONE_TAIL + > > + ACCESS_ONCE(rsp->completed) != rdp->completed] && > > This is a very obscurely written expression. The array index is parsed > as: > (RCU_DONE_TAIL + ACCESS_ONCE(rsp->completed)) != rdp->completed > > Since RCU_DONE_TAIL == 0 and RCU_WAIT_TAIL == 1, this is then equivalent > to: > ACCESS_ONCE(rsp->completed) != rdp->completed > or: > (ACCESS_ONCE(rsp->completed) != rdp->completed) ? RCU_WAIT_TAIL : RCU_DONE_TAIL > > But whyever didn't you write that explicitly? Because the way I think of it is the way that I wrote it -- you should look at the value of the first pointer unless this CPU isn't up to date with the latest grace period, in which case you need to go one step farther up the array of tail pointers. Thanx, Paul > Ben. > > > + !rcu_gp_in_progress(rsp); > > } > > > > /* > > -- > Ben Hutchings > Kids! Bringing about Armageddon can be dangerous. Do not attempt it in > your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'