linux-kernel - Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee

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]

Message-Id: <20161114183926.GO4127@linux.vnet.ibm.com>
Date:   Mon, 14 Nov 2016 10:39:26 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Pranith Kumar <bobby.prani@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Dipankar Sarma <dipankar@...ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Josh Triplett <josh@...htriplett.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        David Howells <dhowells@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Darren Hart <dvhart@...ux.intel.com>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU
 guarantee

On Mon, Nov 14, 2016 at 11:57:46AM -0500, Pranith Kumar wrote:
> Hi Paul,
> 
> On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> > Recent memory-model work deduces the relationships of RCU read-side
> > critical sections and grace periods based on the relationships of
> > accesses within a critical section and accesses preceding and following
> > the grace period.  This commit therefore adds this viewpoint.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > ---
> >  .../RCU/Design/Requirements/Requirements.html      | 25 +++++++++++++++++++++-
> >  1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
> > index a4d3838130e4..81b40cb83435 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -547,7 +547,7 @@ The <tt>rcu_access_pointer()</tt> on line&nbsp;6 is similar to
> >         It could reuse a value formerly fetched from this same pointer.
> >         It could also fetch the pointer from <tt>gp</tt> in a byte-at-a-time
> >         manner, resulting in <i>load tearing</i>, in turn resulting a bytewise
> > -       mash-up of two distince pointer values.
> > +       mash-up of two distinct pointer values.
> >         It might even use value-speculation optimizations, where it makes
> >         a wrong guess, but by the time it gets around to checking the
> >         value, an update has changed the pointer to match the wrong guess.
> > @@ -659,6 +659,29 @@ systems with more than one CPU:
> >         In other words, a given instance of <tt>synchronize_rcu()</tt>
> >         can avoid waiting on a given RCU read-side critical section only
> >         if it can prove that <tt>synchronize_rcu()</tt> started first.
> > +
> > +       <p>
> > +       A related question is &ldquo;When <tt>rcu_read_lock()</tt>
> > +       doesn't generate any code, why does it matter how it relates
> > +       to a grace period?&rdquo;
> > +       The answer if that it is not the relationship of
> 
> s/if/is?

Good catch, fixed!

							Thanx, Paul

> > +       <tt>rcu_read_lock()</tt> itself that is important, but rather
> > +       the relationship of the code within the enclosed RCU read-side
> > +       critical section to the code preceding and following the
> > +       grace period.
> > +       If we take this viewpoint, then a given RCU read-side critical
> > +       section begins before a given grace period when some access
> > +       preceding the grace period observes the effect of some access
> > +       within the critical section, in which case none of the accesses
> > +       within the critical section may observe the effects of any
> > +       access following the grace period.
> > +
> > +       <p>
> > +       As of late 2016, mathematical models of RCU take this
> > +       viewpoint, for example, see slides&nbsp;62 and&nbsp;63
> > +       of the
> > +       <a href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf">2016 LinuxCon EU</a>
> > +       presentation.
> >  </font></td></tr>
> >  <tr><td>&nbsp;</td></tr>
> >  </table>
> > --
> > 2.5.2
> >
> 
> 
> 
> -- 
> Pranith
>