On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote:> On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > If smp_read_barrier_depends() is used to separate not only two reads > > but read pointer and WRITE basing on that pointer (example below) - > > yes. I just doesn't see any example of this in famous > > Documentation/memory-barriers.txt and had no chance to know what you > > use it in this way too. > > Well, Documentation/memory-barriers.txt was intended as a guide for Linux > kernel hackers, and not for hardware architects.Yeah, this goes under the header: memory-barriers.txt is _NOT_ a specification (I seem to keep repeating this).> ------------------------------------------------------------------------ > > commit 955720966e216b00613fcf60188d507c103f0e80 > Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com> > Date: Thu Jan 14 14:17:04 2016 -0800 > > documentation: Subsequent writes ordered by rcu_dereference() > > The current memory-barriers.txt does not address the possibility of > a write to a dereferenced pointer. This should be rare,How are these rare? Isn't: rcu_read_lock() obj = rcu_dereference(ptr); if (!atomic_inc_not_zero(&obj->ref)) obj = NULL; rcu_read_unlock(); a _very_ common thing to do?
On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote:> Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > specification (I seem to keep repeating this).Do we want this ? --- Documentation/memory-barriers.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index a61be39c7b51..433326ebdc26 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1,3 +1,4 @@ + =========================== LINUX KERNEL MEMORY BARRIERS ===========================@@ -5,6 +6,22 @@ By: David Howells <dhowells at redhat.com> Paul E. McKenney <paulmck at linux.vnet.ibm.com> +=========+DISCLAIMER +=========+ +This document is not a specification; it is intentionally (for the sake of +brevity) and unintentionally (due to being human) incomplete. This document is +meant as a guide to using the various memory barriers provided by Linux, but +in case of any doubt (and there are many) please ask. + +I repeat, this document is not a specification of what Linux expects from +hardware. + +====+INDEX +====+ Contents: (*) Abstract memory access model.
On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote:> On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index a61be39c7b51..433326ebdc26 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -1,3 +1,4 @@ > + > ===========================> LINUX KERNEL MEMORY BARRIERS > ===========================> @@ -5,6 +6,22 @@ > By: David Howells <dhowells at redhat.com> > Paul E. McKenney <paulmck at linux.vnet.ibm.com> > > +=========> +DISCLAIMER > +=========> + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document is > +meant as a guide to using the various memory barriers provided by Linux, but > +in case of any doubt (and there are many) please ask.It might be worth adding you and me to the top of the file, to save Paul Cc'ing us on questions (get_maintainer.pl points at poor old Corbet for this file). But yes, it seems that something like this is required. Will
On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote:> On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > > Yes. > > > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > > > If smp_read_barrier_depends() is used to separate not only two reads > > > but read pointer and WRITE basing on that pointer (example below) - > > > yes. I just doesn't see any example of this in famous > > > Documentation/memory-barriers.txt and had no chance to know what you > > > use it in this way too. > > > > Well, Documentation/memory-barriers.txt was intended as a guide for Linux > > kernel hackers, and not for hardware architects. > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > specification (I seem to keep repeating this). > > > ------------------------------------------------------------------------ > > > > commit 955720966e216b00613fcf60188d507c103f0e80 > > Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com> > > Date: Thu Jan 14 14:17:04 2016 -0800 > > > > documentation: Subsequent writes ordered by rcu_dereference() > > > > The current memory-barriers.txt does not address the possibility of > > a write to a dereferenced pointer. This should be rare, > > How are these rare? Isn't: > > rcu_read_lock() > obj = rcu_dereference(ptr); > if (!atomic_inc_not_zero(&obj->ref)) > obj = NULL; > rcu_read_unlock(); > > a _very_ common thing to do?It is, but it provides its own barriers, so does not need to rely on dependency ordering. Thanx, Paul