linux-kernel - Re: [PATCH] rcu/doc: Add a quick quiz to explain further why we need smp_mb__after_unlock

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] [day] [month] [year] [list]

Date:   Fri, 11 Jun 2021 16:48:29 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Uladzislau Rezki <urezki@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH] rcu/doc: Add a quick quiz to explain further why we need
 smp_mb__after_unlock_lock()

On Sat, Jun 12, 2021 at 12:45:17AM +0200, Frederic Weisbecker wrote:
> On Fri, Jun 11, 2021 at 10:25:14AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 11, 2021 at 12:34:32PM +0200, Frederic Weisbecker wrote:
> > Glad to help, and I will reach out to you should someone make the mistake
> > of insisting that I write something in French.  ;-)
> 
> If that can help, we still have frenglish for neutral territories such as airports.
> Not easy to master though...

That does sound dangerous!  ;-)

> > > > ++-----------------------------------------------------------------------+
> > > > +
> > > >  This approach must be extended to include idle CPUs, which need
> > > >  RCU's grace-period memory ordering guarantee to extend to any
> > > >  RCU read-side critical sections preceding and following the current
> > 
> > How about like this?
> > 
> > +-----------------------------------------------------------------------+
> > | **Quick Quiz**:                                                       |
> > +-----------------------------------------------------------------------+
> > | But the chain of rcu_node-structure lock acquisitions guarantees      |
> > | that new readers will see all of the updater's pre-grace-period       |
> > | accesses and also guarantees that the updater's post-grace-period     |
> > | accesses will see all of the old reader's accesses.  So why do we     |
> > | need all of those calls to smp_mb__after_unlock_lock()?               |
> > +-----------------------------------------------------------------------+
> > | **Answer**:                                                           |
> > +-----------------------------------------------------------------------+
> > | Because we must provide ordering for RCU's polling grace-period       |
> > | primitives, for example, get_state_synchronize_rcu() and              |
> > | poll_state_synchronize_rcu().  Consider this code::                   |
> > |                                                                       |
> > |  CPU 0                                     CPU 1                      |
> > |  ----                                      ----                       |
> > |  WRITE_ONCE(X, 1)                          WRITE_ONCE(Y, 1)           |
> > |  g = get_state_synchronize_rcu()           smp_mb()                   |
> > |  while (!poll_state_synchronize_rcu(g))    r1 = READ_ONCE(X)          |
> > |          continue;                                                    |
> > |  r0 = READ_ONCE(Y)                                                    |
> > |                                                                       |
> > | RCU guarantees that the outcome r0 == 0 && r1 == 0 will not           |
> > | happen, even if CPU 1 is in an RCU extended quiescent state           |
> > | (idle or offline) and thus won't interact directly with the RCU       |
> > | core processing at all.                                               |
> > +-----------------------------------------------------------------------+
> 
> Very good, thanks a lot :o)

And thank you!

							Thanx, Paul