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]

Date:	Sun, 14 Oct 2012 18:07:35 -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 Mon, Oct 15, 2012 at 12:54:13AM +0100, Ben Hutchings wrote:
> On Sun, 2012-10-14 at 16:32 -0700, Paul E. McKenney wrote:
> > 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.
> 
> That is not the way you wrote it, since + has higher precedence than !=.

Color me slow and stupid!!!  Indeed, it is working by accident.  I clearly
need to either add the parentheses or use one of the other forms...

								Thanx, Paul

--
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/