Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1225881
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation |
| Date | 2015-09-16 11:30 +0200 |
| Message-ID | <q9hcm-ja-13@gated-at.bofh.it> (permalink) |
| References | <q917z-1wr-3@gated-at.bofh.it> <q92wF-3pz-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Sep 15, 2015 at 10:47:24AM -0700, Paul E. McKenney wrote:
> > diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
> > index 0eca6efc0631..919624634d0a 100644
> > --- a/arch/powerpc/include/asm/barrier.h
> > +++ b/arch/powerpc/include/asm/barrier.h
> > @@ -87,6 +87,7 @@ do { \
> > ___p1; \
> > })
> >
> > +#define smp_mb__release_acquire() smp_mb()
>
> If we are handling locking the same as atomic acquire and release
> operations, this could also be placed between the unlock and the lock.
I think the point was exactly that we need to separate LOCK/UNLOCK from
ACQUIRE/RELEASE.
> However, independently of the unlock/lock case, this definition and
> use of smp_mb__release_acquire() does not handle full ordering of a
> release by one CPU and an acquire of that same variable by another.
> In that case, we need roughly the same setup as the much-maligned
> smp_mb__after_unlock_lock(). So, do we care about this case? (RCU does,
> though not 100% sure about any other subsystems.)
Indeed, that is a hole in the definition, that I think we should close.
> > #define smp_mb__before_atomic() smp_mb()
> > #define smp_mb__after_atomic() smp_mb()
> > #define smp_mb__before_spinlock() smp_mb()
> > diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> > index 0681d2532527..1c61ad251e0e 100644
> > --- a/arch/x86/include/asm/barrier.h
> > +++ b/arch/x86/include/asm/barrier.h
> > @@ -85,6 +85,8 @@ do { \
> > ___p1; \
> > })
> >
> > +#define smp_mb__release_acquire() smp_mb()
> > +
> > #endif
> >
All TSO archs would want this.
> > /* Atomic operations are already serializing on x86 */
> > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> > index b42afada1280..61ae95199397 100644
> > --- a/include/asm-generic/barrier.h
> > +++ b/include/asm-generic/barrier.h
> > @@ -119,5 +119,9 @@ do { \
> > ___p1; \
> > })
> >
> > +#ifndef smp_mb__release_acquire
> > +#define smp_mb__release_acquire() do { } while (0)
>
> Doesn't this need to be barrier() in the case where one variable was
> released and another was acquired?
Yes, I think its very prudent to never let any barrier degrade to less
than barrier().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-15 18:20 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-09-15 19:50 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Peter Zijlstra <peterz@infradead.org> - 2015-09-16 11:30 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-16 12:30 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Peter Zijlstra <peterz@infradead.org> - 2015-09-16 12:50 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-16 13:10 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-17 05:00 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-17 10:00 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-17 20:10 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-21 15:50 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-21 16:20 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-22 00:30 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-22 01:50 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-16 13:50 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon <will.deacon@arm.com> - 2015-09-16 18:40 +0200
Re: [PATCH] barriers: introduce smp_mb__release_acquire and update documentation Boqun Feng <boqun.feng@gmail.com> - 2015-09-17 04:00 +0200
csiph-web