linux-kernel - Re: [ 097/120] rcu: Fix day-one dyntick-idle stall-warning bug

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]

Message-ID: <20121014233249.GB3288@linux.vnet.ibm.com>
Date:	Sun, 14 Oct 2012 16:32:49 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	"Paul E. McKenney" <paul.mckenney@...aro.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	alan@...rguk.ukuu.org.uk, Becky Bruce <bgillbruce@...il.com>,
	Subodh Nijsure <snijsure@...d-net.com>,
	Paul Walmsley <paul@...an.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [ 097/120] rcu: Fix day-one dyntick-idle stall-warning bug

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" <paul.mckenney@...aro.org>
> > 
> > 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'


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/