On Tue, Feb 02, 2016 at 12:20:25PM +, Will Deacon wrote:
[...]
> > > >
> > > > Besides, Will, what's the reason of having a locally transitive chain
> > > > termination? Because on some architectures RELEASE->DEPENDENCY pairs may
> > > > not be locally transitive?
> > >
> > > Well, the follow
On Tue, Feb 02, 2016 at 11:45:59AM +, Will Deacon wrote:
> On Tue, Feb 02, 2016 at 01:19:04PM +0800, Boqun Feng wrote:
> > On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> > > On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > > >
Hello Linus,
On Tue, Feb 02, 2016 at 12:19:04AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:07 AM, Linus Torvalds
> wrote:
> >
> > So we *absolutely* should say that *OF COURSE* these things work:
> >
> > - CPU A:
> >
> >.. initialize data structure -> smp_wmb() -> WRITE_ONCE(pt
Hi Paul,
On Mon, Feb 01, 2016 at 07:54:58PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 01, 2016 at 01:56:22PM +, Will Deacon wrote:
> > On Fri, Jan 29, 2016 at 02:22:53AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 29, 2016 at 09:59:59AM +, Will Deacon wrote:
> > > > On Thu, Jan 28,
ory barrier, implying global
transitivity.
This could give the readers an overview of the usage of this barrier.
> Cc: Boqun Feng
> Cc: Paul E. McKenney
> Cc: Peter Zijlstra
> Signed-off-by: Will Deacon
> ---
>
> Based on Paul's patch to describe local vs global
Hi Maciej,
On Wed, Jan 27, 2016 at 12:41:29PM +, Maciej W. Rozycki wrote:
> On Wed, 27 Jan 2016, Will Deacon wrote:
>
> > > Overall I think it should be safe after all to use SYNC_RELEASE and
> > > other
> > > modern lightweight barriers uncondtionally under the assumption that
> > > arch
On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
> > wrote:
> > >
> > > You might as well just write it as
> > >
> > > struct foo x = READ_ONCE(*ptr);
> > >
Hi Paul,
On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. McKenney wrote:
> On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote:
> > Paul E. McKenney wrote:
> > >
> > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and
> > > smp_read_barrier_depends(), but SYNC_RMB prob
Hi Will,
On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote:
> On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote:
> > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> > > On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > > > PPC Overlapping
elease().
> >
> >
> > But I think removing smp_lwsync() is a good idea and actually I think we
> > can go further to remove __smp_lwsync() and let __smp_load_acquire and
> > __smp_store_release call __lwsync() directly, but that is another thing.
> >
> > Anyway, I will
therwise.
Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other
variants with these helpers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 147 ++
1 file changed, 85 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/incl
Hi all,
I will resend this one to avoid a potential conflict with:
http://article.gmane.org/gmane.linux.kernel/2116880
by open coding smp_lwsync() with:
__asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory");
Regards,
Boqun
signature.asc
Description: PGP signature
On Tue, Jan 05, 2016 at 06:16:48PM +0200, Michael S. Tsirkin wrote:
[snip]
> > > > Another thing is that smp_lwsync() may have a third user(other than
> > > > smp_load_acquire() and smp_store_release()):
> > > >
> > > > http://article.gmane.org/gmane.linux.ports.ppc.embedded/89877
> > > >
> > > >
On Tue, Jan 05, 2016 at 10:51:17AM +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 05, 2016 at 09:36:55AM +0800, Boqun Feng wrote:
> > Hi Michael,
> >
> > On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote:
> > > This defines __smp_xxx barrier
Hi Michael,
On Thu, Dec 31, 2015 at 09:07:42PM +0200, Michael S. Tsirkin wrote:
> This defines __smp_xxx barriers for powerpc
> for use by virtualization.
>
> smp_xxx barriers are removed as they are
> defined correctly by asm-generic/barriers.h
>
> This reduces the amount of arch-specific boile
irq_common_data::state_use_accessors is not designed for public use.
Therefore make it private so that people who write code accessing it
directly will get blamed by sparse. Also #undef the macro
__irqd_to_state after used in header files, so that the macro can't be
misused.
Signed-off-by:
w_spinlock [usertype] *lock
| kernel/rcu/tree.c:4453:25:got struct raw_spinlock [noderef] *
Also, this patch improves compiler.h a little bit by adding comments for
"#else" and "#endif".
Signed-off-by: Boqun Feng
---
include/linux/compiler.h | 12
scripts/chec
replaced with
those wrappers.
Signed-off-by: Boqun Feng
---
kernel/rcu/tree.c| 103 ---
kernel/rcu/tree.h| 42 ++-
kernel/rcu/tree_plugin.h | 26 ++--
3 files changed, 96 insertions(+), 75 deletions(-)
diff --git a
Hi all,
This is v2 of __private.
Link for v1: http://marc.info/?l=linux-sparse&m=144988906932520&w=2
Change since v1:
* #undef __irqd_to_state after used (Peter Zijlstra)
This patchset introduces a __private modifier for sparse to detect misuses of
private members of structs. This could
On Sun, Dec 27, 2015 at 06:53:39PM +1100, Michael Ellerman wrote:
> On Wed, 2015-12-23 at 18:54 +0800, Boqun Feng wrote:
> > On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote:
> > > On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote:
> > > > Hi all,
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote:
> On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote:
>
> > Hi all,
> >
> > This is v6 of the series.
> >
> > Link for v1: https://lkml.org/lkml/2015/8/27/798
> > Link for v2: https://l
On Wed, Dec 23, 2015 at 01:40:05PM +1100, Michael Ellerman wrote:
> On Tue, 2015-12-15 at 22:24 +0800, Boqun Feng wrote:
>
> > Hi all,
> >
> > This is v6 of the series.
> >
> > Link for v1: https://lkml.org/lkml/2015/8/27/798
> > Link for v2: https://l
On Fri, Dec 18, 2015 at 09:12:50AM -0800, Davidlohr Bueso wrote:
> I've left this series testing overnight on a power7 box and so far so good,
> nothing has broken.
Davidlohr, thank you for your testing!
Regards,
Boqun
signature.asc
Description: PGP signature
on the platform without "lwsync", we can use "isync"
rather than "sync" as an acquire barrier. Therefore in
__atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on
UP, "lwsync" if available and "isync" otherwise.
Implement atomic{
Implement xchg{,64}_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg{,64}_relaxed and atomic_{,64}_xchg_relaxed are not
compiler barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include
Hi all,
This is v6 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Link for v4: https://lkml.org/lkml/2015/10/14/670
Link for v5: https://lkml.org/lkml/2015/10/26/141
Changes since
-by: Boqun Feng
---
include/linux/atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 301de78..5f3ee5a 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -34,20 +34,29 @@
* The idea here is to build
piler barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 -
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/includ
On Mon, Dec 14, 2015 at 04:59:45PM +0100, Thomas Gleixner wrote:
> On Mon, 14 Dec 2015, Boqun Feng wrote:
> > Probably something like this(untested, only run "make kernel/irq/")?
> >
> > Subject: [RFC v2 3/3] irq: Privatize irq_common_data::state_use_accessors
>
On Mon, Dec 14, 2015 at 11:03:03AM +0100, Thomas Gleixner wrote:
> On Mon, 14 Dec 2015, Peter Zijlstra wrote:
> > On Sat, Dec 12, 2015 at 10:56:02AM +0800, Boqun Feng wrote:
> > > According to Peter Zijlstra, irq_common_data::state_use_accessors is not
> > > designed for
According to Peter Zijlstra, irq_common_data::state_use_accessors is not
designed for public use. Therefore make it private so that people who
write code accessing it directly will get blamed by sparse.
Signed-off-by: Boqun Feng
---
include/linux/irq.h | 4 ++--
1 file changed, 2 insertions
w_spinlock [usertype] *lock
| kernel/rcu/tree.c:4453:25:got struct raw_spinlock [noderef] *
Also, this patch improves compiler.h a little bit by adding comments for
"#else" and "#endif".
Signed-off-by: Boqun Feng
---
include/linux/compiler.h | 12
scripts/chec
replaced with
those wrappers.
Signed-off-by: Boqun Feng
---
kernel/rcu/tree.c| 103 ---
kernel/rcu/tree.h| 42 ++-
kernel/rcu/tree_plugin.h | 26 ++--
3 files changed, 96 insertions(+), 75 deletions(-)
diff --git a
Hi all,
As I proposed:
http://marc.info/?l=linux-arm-kernel&m=144944469805753
, we can define a __private modifier for sparse to detect misuses of private
members of structs. This could make maintenace a little easier and prevent some
potential bugs.
This patchset serves as a POC and consists o
On Thu, Dec 03, 2015 at 01:40:14PM +0100, Peter Zijlstra wrote:
[snip]
> + *
> + * CPU0 (schedule) CPU1 (try_to_wake_up) CPU2 (schedule)
> + *
> + * LOCK rq(0)->lock LOCK X->pi_lock
> + * dequeue X
> + * sched-out X
> + * smp_store_release(X->on_cpu, 0);
> + *
> + *sm
On Tue, Nov 24, 2015 at 11:52:12PM +0800, Boqun Feng wrote:
> Hi Daniel,
>
> On Tue, Nov 24, 2015 at 02:03:06PM +0100, Daniel Wagner wrote:
> > rcu_nocb_gp_cleanup() is called while holding rnp->lock. Currently,
> > this is okay because the wake_up_all() in rcu_nocb_g
Hi Daniel,
On Tue, Nov 24, 2015 at 02:03:06PM +0100, Daniel Wagner wrote:
> rcu_nocb_gp_cleanup() is called while holding rnp->lock. Currently,
> this is okay because the wake_up_all() in rcu_nocb_gp_cleanup() will
> not enable the IRQs. lockdep is happy.
>
> By switching over using swait this is
Commit-ID: 978e5a3692c3b674b4c7c412e96835fd996c2ff4
Gitweb: http://git.kernel.org/tip/978e5a3692c3b674b4c7c412e96835fd996c2ff4
Author: Boqun Feng
AuthorDate: Wed, 4 Nov 2015 18:52:45 +0800
Committer: Ingo Molnar
CommitDate: Mon, 23 Nov 2015 10:01:58 +0100
atomics: Add test for atomic
On Fri, Nov 20, 2015 at 03:18:12PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 20, 2015 at 10:08:50PM +0800, Boqun Feng wrote:
> > Hi Peter,
> >
> > On Fri, Nov 20, 2015 at 11:02:30AM +0100, Peter Zijlstra wrote:
> > [snip]
> > > + * BLOCKING -- aka. SL
Hi Peter,
On Fri, Nov 20, 2015 at 11:02:30AM +0100, Peter Zijlstra wrote:
[snip]
> + * BLOCKING -- aka. SLEEP + WAKEUP
> + *
> + * For blocking we (obviously) need to provide the same guarantee as for
> + * migration. However the means are completely different as there is no lock
> + * chain to p
On Thu, Nov 12, 2015 at 04:00:58PM +0100, Oleg Nesterov wrote:
> On 11/12, Boqun Feng wrote:
[snip]
> >
> > Hmm.. probably incorrect.. because the ACQUIRE semantics of spin_lock()
> > only guarantees that the memory operations following spin_lock() can't
> > be r
On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote:
[snip]
>
> I cannot resist suggesting that any lock that interacts with
> spin_unlock_wait() must have all relevant acquisitions followed by
> smp_mb__after_unlock_lock().
>
But
1. This would expand the purpose of smp_mb__af
On Wed, Nov 11, 2015 at 08:39:53PM +0100, Oleg Nesterov wrote:
> On 11/11, Peter Zijlstra wrote:
> >
> > On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> >
> > > Just be curious, should spin_unlock_wait() semantically be an ACQUIRE?
> >
>
On Wed, Nov 11, 2015 at 05:39:40PM +0800, Boqun Feng wrote:
> Hi Oleg,
>
> On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
> [snip]
> >
> > Unfortunately this doesn't look exactly right...
> >
> > spin_unlock_wait() is not equal to "
Hi Oleg,
On Tue, Nov 03, 2015 at 06:59:58PM +0100, Oleg Nesterov wrote:
[snip]
>
> Unfortunately this doesn't look exactly right...
>
> spin_unlock_wait() is not equal to "while (locked) relax", the latter
> is live-lockable or at least sub-optimal: we do not really need to spin
Just be curious
that we can examine their assembly code.
Signed-off-by: Boqun Feng
---
This is separated from the patchset of powerpc atomic variants implementation,
whose link is:
https://lkml.org/lkml/2015/10/26/141
Based on locking/core branch of the tip tree, tested by 0day.
lib/atomic64_test.c | 120
On Mon, Nov 02, 2015 at 09:22:40AM +0800, Boqun Feng wrote:
> > On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> > > To summerize:
> > >
> > > patch 1(split to two), 3, 4(remove inc/dec implementation), 5, 6 sent as
> > > powerpc patches for
0/14/970
To fix this, we define PPC_ATOMIC_ENTRY_BARRIER as "sync" to guarantee
the fully-ordered semantics.
This also makes futex atomics fully ordered, which can avoid possible
memory ordering problems if userspace code relies on futex system call
for fully ordered semantics.
Cc: # 3.4+
Signed-off-b
ly
ordered" for PPC_ATOMIC_ENTRY_BARRIER definition.
Cc: # 3.4+
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/cmpxchg.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/cmpxchg.h
b/arch/powerpc/include/asm/cmpxchg.h
in
On Fri, Oct 30, 2015 at 08:56:33AM +0800, Boqun Feng wrote:
> On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> > On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> > > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > > > This pa
On Tue, Oct 27, 2015 at 11:06:52AM +0800, Boqun Feng wrote:
> On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > > This patch fixes two problems to make value-returning atomics and
> > > {cm
On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote:
> On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote:
> > This patch fixes two problems to make value-returning atomics and
> > {cmp}xchg fully ordered on PPC.
>
> Hi Boqun,
>
> Can you please split
On Mon, Oct 26, 2015 at 02:26:01PM +0100, Peter Zijlstra wrote:
> On Mon, Oct 26, 2015 at 01:59:44PM +0100, Daniel Wagner wrote:
> > Hi Boqun,
> >
> > On 10/26/2015 01:04 PM, Boqun Feng wrote:
> > > On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
>
Hi Daniel,
On Tue, Oct 20, 2015 at 09:28:07AM +0200, Daniel Wagner wrote:
> +
> +/*
> + * The thing about the wake_up_state() return value; I think we can ignore
> it.
> + *
> + * If for some reason it would return 0, that means the previously waiting
> + * task is already running, so it will obs
RIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: # 3.4+
Signed-off-by: Boqun Feng
---
On Mon, Oct 26, 2015 at 05:50:52PM +0800, Boqun Feng wrote:
> This patch fixes two problems to make value-returning atomics and
> {cmp}xchg fully ordered on PPC.
>
> According to memory-barriers.txt:
>
> > Any atomic operation that modifies some state in memory and returns
-by: Boqun Feng
---
include/linux/atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 27e580d..947c1dc 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -43,20 +43,29 @@ static inline int atomic_read_ctrl
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm
on the platform without "lwsync", we can use "isync"
rather than "sync" as an acquire barrier. Therefore in
__atomic_op_acquire() we use PPC_ACQUIRE_BARRIER, which is barrier() on
UP, "lwsync" if available and "isync" otherwise.
Implement atomic{
piler barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 -
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/includ
Hi all,
This is v5 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Link for v4: https://lkml.org/lkml/2015/10/14/670
Changes since v4:
* define PPC_ATOMIC_ENTRY_BARRIER as "s
that we can examine their assembly code.
Signed-off-by: Boqun Feng
---
lib/atomic64_test.c | 120 ++--
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index 83c33a5b..18e422b 100644
--- a/lib
RIER and PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics
of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit
b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics").
Cc: # 3.4+
Signed-off-by: Boqun Feng
---
On Mon, Oct 26, 2015 at 02:20:21PM +1100, Paul Mackerras wrote:
> On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > > I am not seeing a sync there, but I really have to defer to the
> > > maintainers on this one
On Mon, Oct 26, 2015 at 11:20:01AM +0900, Michael Ellerman wrote:
>
> Sorry guys, these threads are so long I tend not to read them very actively :}
>
> Looking at the system call path, the straight line path does not include any
> barriers. I can't see any hidden in macros either.
>
> We also h
On Wed, Oct 21, 2015 at 12:36:38PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> > > I am not seeing a sync there, but I really have to defer to the
> > > maintainers on this o
On Sat, Oct 24, 2015 at 07:53:56PM +0800, Boqun Feng wrote:
> On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote:
> >
> > Right, futexes are a pain; and I think we all agreed we didn't want to
> > go rely on implementation details unless we absolutely _
On Sat, Oct 24, 2015 at 12:26:27PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 22, 2015 at 08:07:16PM +0800, Boqun Feng wrote:
> > On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> >
On Wed, Oct 21, 2015 at 09:48:25PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 21, 2015 at 12:35:23PM -0700, Paul E. McKenney wrote:
> > > > > > I ask this because I recall Peter once bought up a discussion:
> > > > > >
> > > > > > https://lkml.org/lkml/2015/8/26/596
>
> > > So a full barrier on o
On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote:
> On Tue, Oct 20, 2015 at 11:21:47AM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 20, 2015 at 03:15:32PM +0800, Boqun Feng wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > &
On Mon, Oct 12, 2015 at 04:30:48PM -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2015 at 07:33:28PM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2015 at 10:43:27AM -0700, Paul E. McKenney wrote:
> > > On Fri, Oct 09, 2015 at 10:51:29AM +0100, Will Deacon wrote:
[snip]
>
> > > > We could also i
On Mon, Oct 19, 2015 at 12:23:24PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 19, 2015 at 09:17:18AM +0800, Boqun Feng wrote:
> > This is confusing me right now. ;-)
> >
> > Let's use a simple example for only one primitive, as I understand it,
> > if we say a pr
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
>
> Am I missing something here? If not, it seems to me that you need
> the leading lwsync to instead be a sync.
>
> Of course, if I am not missing something, then this applies also to the
> value-returning RMW atomic operations t
On Mon, Oct 19, 2015 at 08:46:02PM -0700, Davidlohr Bueso wrote:
> On Tue, 20 Oct 2015, Boqun Feng wrote:
>
> >>@@ -93,7 +94,7 @@ static __always_inline void queued_spin_unlock(struct
> >>qspinlock *lock)
> >>/*
> >> * smp_mb__before_atomic
Hi Waiman,
On Thu, Oct 15, 2015 at 06:51:03PM -0400, Waiman Long wrote:
> This patch replaces the cmpxchg() and xchg() calls in the native
> qspinlock code with the more relaxed _acquire or _release versions of
> those calls to enable other architectures to adopt queued spinlocks
> with less memor
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2015 at 10:31:38AM +0200, Peter Zijlstra wrote:
[snip]
> >
> > So lots of little confusions added up to complete fail :-{
> >
> > Mostly I think it was the UNLOCK x + LOCK x are fully ordered (where I
> > forgot: but n
On Thu, Oct 15, 2015 at 09:30:40AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
[snip]
> >
> > > Why not try creating a longer litmus test that requires P0
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 14, 2015 at 11:55:56PM +0800, Boqun Feng wrote:
> > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> > versions all need to imply a full barrier, however they are now just
>
On Thu, Oct 15, 2015 at 11:35:44AM +0100, Will Deacon wrote:
>
> So arm64 is ok. Doesn't lwsync order store->store observability for PPC?
>
I did some litmus and put the result here. My understanding might be
wrong, and I think Paul can explain the lwsync and store->store order
better ;-)
When
On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
[snip]
> >
> > I'm afraid more than that, the above litmus also shows that
> >
> > CPU 0
Hi Paul,
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
[snip]
> > To that end, the herd tool can make a diagram of what it thought
> > happened, and I have attached it. I used this diagram to try and
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
>
On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > Suppose we have something like the following, where "a" and "x" are both
> > > initially ze
piler barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 10 +++
arch/powerpc/include/asm/cmpxchg.h | 149 -
2 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/includ
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm
defined as smp_lwsync() + _relaxed +
smp_mb__after_atomic() to guarantee a full barrier.
Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other
variants with these helpers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.h | 116 ---
PPC_ATOMIC_EXIT_BARRIER in
__{cmp,}xchg_{u32,u64} respectively to guarantee a full barrier
semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg().
This patch is a complement of commit b97021f85517 ("powerpc: Fix
atomic_xxx_return barrier semantics").
Acked-by: Michael Ellerman
Cc: # 3.4+
Signed-off-by:
-by: Boqun Feng
---
include/linux/atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 27e580d..947c1dc 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -43,20 +43,29 @@ static inline int atomic_read_ctrl
that we can examine their assembly code.
Signed-off-by: Boqun Feng
---
lib/atomic64_test.c | 120 ++--
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/lib/atomic64_test.c b/lib/atomic64_test.c
index 83c33a5b..18e422b 100644
--- a/lib
Hi all,
This is v4 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Changes since v3:
* avoid to introduce smp_acquire_barrier__after_atomic()
(Will Deacon)
* e
On Wed, Oct 14, 2015 at 10:06:13AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 08:51:34AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
>
> > > Thanks for fixing this. In future you should send a patch like this as a
On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > Putting a barrier in the middle of that critical section is probably a
> > >
On Tue, Oct 13, 2015 at 09:35:54PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:21:32PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
> [snip]
> > > +/*
> > > + * Since {add,sub}_return_relaxed and xchg_relaxed ar
On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
> On Mon, 2015-10-12 at 22:30 +0800, Boqun Feng wrote:
> > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> > versions all need to imply a full barrier, however they are now just
> > RELE
On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > Putting a barrier in the middle of that critical section is probably a
> > >
On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:32:59PM +0800, Boqun Feng wrote:
[snip]
> >
> > Mostly because of the comments in include/linux/atomic.h:
> >
> > * For compound atomics performing both a load and a store, ACQ
On Tue, Oct 13, 2015 at 10:32:59PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:24:04PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> > > Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> > &
On Tue, Oct 13, 2015 at 02:24:04PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2015 at 10:14:06PM +0800, Boqun Feng wrote:
> > Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
> > which _release variants can be built.
> >
> > To avoid super
On Tue, Oct 13, 2015 at 02:21:32PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
[snip]
> > +/*
> > + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> > + * a "bne-" instruction at the end, so
On Tue, Oct 13, 2015 at 12:02:00AM +0800, Fengguang Wu wrote:
> On Mon, Oct 12, 2015 at 11:42:24PM +0800, Boqun Feng wrote:
> > Hi Fengguang,
> >
> > On Mon, Oct 12, 2015 at 11:29:14PM +0800, Fengguang Wu wrote:
> > > Hi Boqun,
> > >
> > > The base
801 - 900 of 1017 matches
Mail list logo
