On Mon, May 06, 2019 at 06:42:38PM +0200, Andrea Parri wrote: > On Fri, May 03, 2019 at 01:13:44PM -0400, Alan Stern wrote: > > The description of smp_mb__before_atomic() and smp_mb__after_atomic() > > in Documentation/atomic_t.txt is slightly terse and misleading. It > > does not clearly state which other instructions are ordered by these > > barriers. > > > > This improves the text to make the actual ordering implications clear, > > and also to explain how these barriers differ from a RELEASE or > > ACQUIRE ordering. > > > > Signed-off-by: Alan Stern <st...@rowland.harvard.edu> > > CC: Peter Zijlstra <pet...@infradead.org> > > I understand that this does indeed better describe the intended semantics: > > Acked-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
I reverted the original and applied this one. It will become visible at the next rebase. > Now we would only need to fix the implementations and a few (mis)uses. ;-) You do have a start on this task! ;-) Thanx, Paul > Andrea > > > > > > --- > > > > v2: Update the explanation: These barriers do provide order for > > accesses on the far side of the atomic RMW operation. > > > > > > Documentation/atomic_t.txt | 17 +++++++++++++---- > > 1 file changed, 13 insertions(+), 4 deletions(-) > > > > Index: usb-devel/Documentation/atomic_t.txt > > =================================================================== > > --- usb-devel.orig/Documentation/atomic_t.txt > > +++ usb-devel/Documentation/atomic_t.txt > > @@ -170,8 +170,14 @@ The barriers: > > > > smp_mb__{before,after}_atomic() > > > > -only apply to the RMW ops and can be used to augment/upgrade the ordering > > -inherent to the used atomic op. These barriers provide a full smp_mb(). > > +only apply to the RMW atomic ops and can be used to augment/upgrade the > > +ordering inherent to the op. These barriers act almost like a full > > smp_mb(): > > +smp_mb__before_atomic() orders all earlier accesses against the RMW op > > +itself and all accesses following it, and smp_mb__after_atomic() orders all > > +later accesses against the RMW op and all accesses preceding it. However, > > +accesses between the smp_mb__{before,after}_atomic() and the RMW op are not > > +ordered, so it is advisable to place the barrier right next to the RMW > > atomic > > +op whenever possible. > > > > These helper barriers exist because architectures have varying implicit > > ordering on their SMP atomic primitives. For example our TSO architectures > > @@ -195,7 +201,9 @@ Further, while something like: > > atomic_dec(&X); > > > > is a 'typical' RELEASE pattern, the barrier is strictly stronger than > > -a RELEASE. Similarly for something like: > > +a RELEASE because it orders preceding instructions against both the read > > +and write parts of the atomic_dec(), and against all following instructions > > +as well. Similarly, something like: > > > > atomic_inc(&X); > > smp_mb__after_atomic(); > > @@ -227,7 +235,8 @@ strictly stronger than ACQUIRE. As illus > > > > This should not happen; but a hypothetical atomic_inc_acquire() -- > > (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome, > > -since then: > > +because it would not order the W part of the RMW against the following > > +WRITE_ONCE. Thus: > > > > P1 P2 > > > > >