linux-kernel - Re: [PATCH 8/9] jrcu: fix broken rcu

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: <20110323134628.GA4352@tsunami.ccur.com>
Date:	Wed, 23 Mar 2011 09:46:28 -0400
From:	Joe Korty <joe.korty@...r.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	"fweisbec@...il.com" <fweisbec@...il.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"laijs@...fujitsu.com" <laijs@...fujitsu.com>,
	"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
	"dhowells@...hat.com" <dhowells@...hat.com>,
	"loic.minier@...aro.org" <loic.minier@...aro.org>,
	"dhaval.giani@...il.com" <dhaval.giani@...il.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"josh@...htriplett.org" <josh@...htriplett.org>,
	"houston.jim@...cast.net" <houston.jim@...cast.net>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 8/9] jrcu: fix broken rcu_barrier

On Wed, Mar 23, 2011 at 02:35:24AM -0400, Paul E. McKenney wrote:
> On Mon, Mar 14, 2011 at 06:09:28PM -0400, Joe Korty wrote:
> > On Mon, Mar 14, 2011 at 04:47:18AM -0400, Paul E. McKenney wrote:
> > > On Sun, Mar 13, 2011 at 11:50:44PM -0400, Joe Korty wrote:
> > > > +void rcu_barrier(void)
> > > > +{
> > > > +	synchronize_sched();
> > > > +	synchronize_sched();
> > > > +}
> > > 
> > > This is still broken.  You need to wait until all pre-existing RCU
> > > callbacks on all CPUs have been invoked.  Although this does guarantee
> > > that all callbacks on the current CPU have been invoked, if one of the
> > > other CPUs is busy, it might not yet have processed the callbacks from
> > > earlier grace periods.  The usual way to take care of this is to post
> > > a callback on each CPU, then wait for them all to be invoked.
> > 
> > Hi Paul,
> > JRCU (eventually) chains together all callbacks from all
> > cpus into a single queue and then it expires that single
> > queue.  So the double synchronize_sched() should work as
> > a rcu_barrier implementation.
> 
> Hello, Joe,
> 
> So the following grace period is not permitted to start until all of
> the callbacks from the prior grace period have been invoked?

Yes, it is all synchronized.  Every cpu's current batch is
closed off at the same time.  We tolerate some fuzz in the
timing, but that is not the same as being unsynchronized.

This happens as an automatic side effect of doing
everything (except for call_rcu) from a single CPU.

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