Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Mon, Apr 24, 2023 at 12:29:00PM -0500, Segher Boessenkool wrote: > On Mon, Apr 24, 2023 at 08:28:55AM -0700, Boqun Feng wrote: > > On Mon, Apr 24, 2023 at 10:13:51AM -0500, Segher Boessenkool wrote: > > > At what points can r13 change? Only when some particular function

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Mon, Apr 24, 2023 at 10:13:51AM -0500, Segher Boessenkool wrote: > Hi! > > On Mon, Apr 24, 2023 at 11:14:00PM +1000, Michael Ellerman wrote: > > Boqun Feng writes: > > > On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote: > > >> On Sat, Apr 22

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote: > On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote: > > > > Dear PowerPC and RCU developers: > > During the RCU torture test on mainline (on the VM of Opensource Lab > > of Oregon State University), SRCU-P failed with

Re: [PATCH v6 1/9] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32

Hi, On Wed, Mar 31, 2021 at 02:30:32PM +, guo...@kernel.org wrote: > From: Guo Ren > > Some architectures don't have sub-word swap atomic instruction, > they only have the full word's one. > > The sub-word swap only improve the performance when: > NR_CPUS < 16K > * 0- 7: locked byte > *

Re: [PATCH 3/3] powerpc: rewrite atomics to use ARCH_ATOMIC

On Tue, Dec 22, 2020 at 01:52:50PM +1000, Nicholas Piggin wrote: > Excerpts from Boqun Feng's message of November 14, 2020 1:30 am: > > Hi Nicholas, > > > > On Wed, Nov 11, 2020 at 09:07:23PM +1000, Nicholas Piggin wrote: > >> All the cool kids are doing it. > >> > >> Signed-off-by: Nicholas

Re: [PATCH 3/3] powerpc: rewrite atomics to use ARCH_ATOMIC

Hi Nicholas, On Wed, Nov 11, 2020 at 09:07:23PM +1000, Nicholas Piggin wrote: > All the cool kids are doing it. > > Signed-off-by: Nicholas Piggin > --- > arch/powerpc/include/asm/atomic.h | 681 ++--- > arch/powerpc/include/asm/cmpxchg.h | 62 +-- > 2 files changed,

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Fri, May 18, 2018 at 02:17:17PM -0400, Mathieu Desnoyers wrote: > - On May 17, 2018, at 7:50 PM, Boqun Feng boqun.f...@gmail.com wrote: > [...] > >> > I think you're right. So we have to introduce callsite to rseq_syscall() > >> > in syscall path, something l

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Thu, May 17, 2018, at 11:28 PM, Mathieu Desnoyers wrote: > - On May 16, 2018, at 9:19 PM, Boqun Feng boqun.f...@gmail.com wrote: > > > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > >> - On May 16, 2018, at 12:18 PM, Peter Zijlstra

Re: [PATCH 07/14] powerpc: Add support for restartable sequences

On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > - On May 16, 2018, at 12:18 PM, Peter Zijlstra pet...@infradead.org wrote: > > > On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers wrote: > >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > >> index

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Fri, Jul 28, 2017 at 12:09:56PM -0700, Paul E. McKenney wrote: > On Fri, Jul 28, 2017 at 11:41:29AM -0700, Paul E. McKenney wrote: > > On Fri, Jul 28, 2017 at 07:55:30AM -0700, Paul E. McKenney wrote: > > > On Fri, Jul 28, 2017 at 08:54:16PM +0800, Boqun Feng wrote: > >

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

On Fri, Jul 28, 2017 at 11:41:29AM -0700, Paul E. McKenney wrote: > On Fri, Jul 28, 2017 at 07:55:30AM -0700, Paul E. McKenney wrote: > > On Fri, Jul 28, 2017 at 08:54:16PM +0800, Boqun Feng wrote: > > > Hi Jonathan, > > > > > > FWIW, there is wakeup-missing

Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?

ctive() check in swake_up() and swake_up_all(). Reported-by: Steven Rostedt <rost...@goodmis.org> Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- kernel/sched/swait.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c index 3d5610dcce11..2

Re: [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions

.ozlabs.org> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Alan Stern <st...@rowland.harvard.edu> > Cc: Andrea Parri <parri.and...@gmail.com> > Cc: Linus Torvalds <torva...@linux-foundation.org> Acked

Re: [PATCH v8 3/6] powerpc: lib/locks.c: Add cpu yield/wake helper function

On Mon, Dec 05, 2016 at 10:19:23AM -0500, Pan Xinhui wrote: > Add two corresponding helper functions to support pv-qspinlock. > > For normal use, __spin_yield_cpu will confer current vcpu slices to the > target vcpu(say, a lock holder). If target vcpu is not specified or it > is in running state,

Re: [PATCH v8 2/6] powerpc: pSeries/Kconfig: Add qspinlock build config

On Mon, Dec 05, 2016 at 10:19:22AM -0500, Pan Xinhui wrote: > pSeries/powerNV will use qspinlock from now on. > > Signed-off-by: Pan Xinhui > --- > arch/powerpc/platforms/pseries/Kconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git

Re: [PATCH v8 1/6] powerpc/qspinlock: powerpc support qspinlock

On Mon, Dec 05, 2016 at 10:19:21AM -0500, Pan Xinhui wrote: > This patch add basic code to enable qspinlock on powerpc. qspinlock is > one kind of fairlock implementation. And seen some performance improvement > under some scenarios. > > queued_spin_unlock() release the lock by just one write of

[RFC v2] powerpc: xmon: Add address lookup for percpu symbols

for percpu symbols. Usage of "lp" is similar to "ls", except that we could add a cpu number to choose the variable of which cpu we want to lookup. If no cpu number is given, lookup for current cpu. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- v1 --> v2: o

[RFC] powerpc: xmon: Add address lookup for percpu symbols

for percpu symbols. Usage of "lp" is similar to "ls", except that we could add a cpu number to choose the variable of which cpu we want to lookup. If no cpu number is given, lookup for current cpu. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- arch/powerpc/xmon/xmon.c

Re: [PATCH v5 9/9] Documentation: virtual: kvm: Support vcpu preempted check

On Thu, Oct 20, 2016 at 05:27:54PM -0400, Pan Xinhui wrote: > Commit ("x86, kvm: support vcpu preempted check") add one field "__u8 > preempted" into struct kvm_steal_time. This field tells if one vcpu is > running or not. > > It is zero if 1) some old KVM deos not support this filed. 2) the vcpu

Re: [PATCH v7 4/6] powerpc: lib/locks.c: Add cpu yield/wake helper function

Hi Xinhui, On Mon, Sep 19, 2016 at 05:23:55AM -0400, Pan Xinhui wrote: > Add two corresponding helper functions to support pv-qspinlock. > > For normal use, __spin_yield_cpu will confer current vcpu slices to the > target vcpu(say, a lock holder). If target vcpu is not specified or it > is in

[PATCH] powerpc, hotplug: Avoid to touch non-existent cpumasks.

ition check on whether the id is no less than nr_cpu_ids in the sibling CPU iteration code. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- arch/powerpc/kernel/smp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/ker

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

On Tue, Jun 28, 2016 at 11:39:18AM +0800, xinhui wrote: [snip] > > > +{ > > > + struct lppaca *lp = _of(cpu); > > > + > > > + if (unlikely(!(lppaca_shared_proc(lp) || > > > + lppaca_dedicated_proc(lp > > > > Do you want to detect whether we are running in a guest(ie. pseries >

Re: [PATCH 2/3] powerpc/spinlock: support vcpu preempted check

and dedicated mode. > So add lppaca_dedicated_proc macro in lppaca.h > > Suggested-by: Boqun Feng <boqun.f...@gmail.com> > Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com> > --- > arch/powerpc/include/asm/lppaca.h | 6 ++ > arch/powerpc/include/asm/spi

Re: [PATCH 1/3] kernel/sched: introduce vcpu preempted check interface

On Mon, Jun 27, 2016 at 01:41:28PM -0400, Pan Xinhui wrote: > this supports to fix lock holder preempted issue which run as a guest > > for kernel users, we could use bool vcpu_is_preempted(int cpu) to detech > if one vcpu is preempted or not. > > The default implementation is a macrodefined by

[PATCH v4] powerpc: spinlock: Fix spin_unlock_wait()

atch therefore fixes the issue and also cleans the arch_spin_unlock_wait() a little bit by removing superfluous memory barriers in loops and consolidating the implementations for PPC32 and PPC64 into one. Suggested-by: "Paul E. McKenney" <paul...@linux.vnet.ibm.com> Signed-off-by: Boqun F

Re: [PATCH v3] powerpc: spinlock: Fix spin_unlock_wait()

On Fri, Jun 10, 2016 at 01:25:03AM +0800, Boqun Feng wrote: > On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote: > > On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote: > > > On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote: > > > &

Re: [PATCH v3] powerpc: spinlock: Fix spin_unlock_wait()

On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote: > On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote: > > On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote: > > > > > > Ok; what tree does this go in? I have this dependent series which I'd > > > > like to get

Re: [v2] powerpc: spinlock: Fix spin_unlock_wait()

On Mon, Jun 06, 2016 at 02:52:05PM +1000, Michael Ellerman wrote: > On Fri, 2016-03-06 at 03:49:48 UTC, Boqun Feng wrote: > > There is an ordering issue with spin_unlock_wait() on powerpc, because > > the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering &g

[PATCH v2] powerpc: spinlock: Fix spin_unlock_wait()

n_unlock() -> spin_lock() This patch therefore fixes the issue and also cleans the arch_spin_unlock_wait() a little bit by removing superfluous memory barriers in loops and consolidating the implementations for PPC32 and PPC64 into one. Suggested-by: "Paul E. McKenney" <paul...@

[PATCH 4/4] rcutorture: Don't specify the cpu type of QEMU on PPC

Do not restrict the cpu type to POWER7 for QEMU as we have POWER8 now. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- tools/testing/selftests/rcutorture/bin/functions.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/bin/functi

[PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

The option "-soundhw pcspk" gives me a error on PPC as follow: qemu-system-ppc64: ISA bus not available for pcspk , which means this option doesn't work on ppc by default. So simply make this an x86-specific option via identify_qemu_args(). Signed-off-by: Boqun Feng <boqun.f

[PATCH 2/4] rcutorture: Use vmlinux as the fallback kernel image

if ${TORTURE_BOOT_IMAGE} is not set on non-x86 architectures, also fixes several places that hard-code "bzImage" as $KERNEL. This also fixes a problem that PPC doesn't have a bzImage file as build results. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- tools/testing/selftest

[PATCH 1/4] rcutorture/doc: Add a new way to create initrd using dracut

where host's initramfs couldn't be used. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- tools/testing/selftests/rcutorture/doc/initrd.txt | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/testing/selftests/rcutorture/doc/initrd.txt b/tools/testing/sel

[PATCH 0/4] rcutorture: Several fixes to run selftest scripts on PPC

certainly not an expert of qemu or bash programming, there may be something I am missing in those patches. So tests and comments are welcome ;-) Regards, Boqun Boqun Feng (4): rcutorture/doc: Add a new way to create initrd using dracut rcutorture: Use vmlinux as the fallback kernel image

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 10:50:34PM +0800, Boqun Feng wrote: > > Sorry, my bad, we can't implement cmpxchg like this.. please ignore > this, I should really go to bed soon... > > But still, we can save the "tmp" for xchg() I think. > No.. we can't. Sorry for all

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote: > On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: > > From: Pan Xinhui <xinhui@linux.vnet.ibm.com> > > > > Implement xchg{u8,u16}{local,relaxed}, and > > cmpxchg{u8,u16}{,local,acquire,r

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 09:58:17PM +0800, Boqun Feng wrote: > On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: > > From: Pan Xinhui <xinhui@linux.vnet.ibm.com> > > > > Implement xchg{u8,u16}{local,relaxed}, and > > cmpxchg{u8,u16}{,local,acquire,r

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: > From: Pan Xinhui > > Implement xchg{u8,u16}{local,relaxed}, and > cmpxchg{u8,u16}{,local,acquire,relaxed}. > > It works on all ppc. > > remove volatile of first parameter in __cmpxchg_local and

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Fri, Apr 22, 2016 at 09:59:22AM +0800, Pan Xinhui wrote: > On 2016年04月21日 23:52, Boqun Feng wrote: > > On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > >> On 2016年04月20日 22:24, Peter Zijlstra wrote: > >>> On Wed, Apr 20, 2016 at 09:2

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: > On 2016年04月20日 22:24, Peter Zijlstra wrote: > > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > > > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) > >> \ > >> +static __always_inline

[PATCH powerpc/next RESEND] powerpc: spinlock: Fix spin_unlock_wait()

ing the implementations for PPC32 and PPC64 into one. Suggested-by: "Paul E. McKenney" <paul...@linux.vnet.ibm.com> Signed-off-by: Boqun Feng <boqun.f...@gmail.com> Reviewed-by: "Paul E. McKenney" <paul...@linux.vnet.ibm.com> --- arch/powerpc/include/asm/spinl

Re: [PATCH] arch/powerpc: use BUILD_BUG() when detect unfit {cmp}xchg, size

t; } > - __xchg_called_with_bad_pointer(); > + BUILD_BUG(); Maybe we can use BUILD_BUG_ON_MSG(1, "Unsupported size for xchg"), which could provide more information. With or without this verbosity: Acked-by: Boqun Feng <boqun.f...@gmail.com> Regards, Boqun >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

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

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

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 > > >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

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

Re: [PATCH v2 15/32] powerpc: define __smp_xxx

> > > > > > 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 modify my

Re: [PATCH v2 15/32] powerpc: define __smp_xxx

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 barr

Re: [PATCH v2 15/32] powerpc: define __smp_xxx

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 > > > > > > >

Re: [PATCH v6 2/4] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

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

[PATCH RESEND v6 2/4] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

therwise. Implement atomic{,64}_{add,sub,inc,dec}_return_relaxed, and build other variants with these helpers. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- arch/powerpc/include/asm/atomic.h | 147 ++ 1 file changed, 85 insertions(+), 62 deletions(-

Re: [PATCH v2 15/32] powerpc: define __smp_xxx

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

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

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 al

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

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

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

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

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

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

[PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

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

[PATCH v6 1/4] atomics: Allow architectures to define their own __atomic_op_* helpers

-by: Boqun Feng <boqun.f...@gmail.com> --- 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 @@ * Th

[PATCH v6 3/4] powerpc: atomic: Implement acquire/release/relaxed variants for xchg

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 <boqun.f...@gmail.

[PATCH v6 4/4] powerpc: atomic: Implement acquire/release/relaxed variants for cmpxchg

barriers. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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

[PATCH v6 2/4] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

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{

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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

[PATCH powerpc/next 1/2] powerpc: Make value-returning atomics fully ordered

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: <sta...@vger

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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

[PATCH powerpc/next 2/2] powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

s fully ordered" for PPC_ATOMIC_ENTRY_BARRIER definition. Cc: <sta...@vger.kernel.org> # 3.4+ Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- arch/powerpc/include/asm/cmpxchg.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/inclu

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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

[PATCH tip/locking/core v5 2/6] atomics: Add test for atomic operations with _relaxed variants

that we can examine their assembly code. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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 83

[PATCH tip/locking/core v5 6/6] powerpc: atomic: Implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants

barriers. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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

[PATCH tip/locking/core v5 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

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{

[PATCH tip/locking/core v5 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

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

[PATCH tip/locking/core v5 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers

-by: Boqun Feng <boqun.f...@gmail.com> --- 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

Re: [PATCH tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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

[PATCH RESEND tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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: <sta...@vger.kernel.org> # 3.4+ Sig

[PATCH tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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: <sta...@vger.kernel.org> # 3.4+ Sig

[PATCH tip/locking/core v5 5/6] powerpc: atomic: Implement xchg_* and atomic{, 64}_xchg_* variants

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 <boqun.f...@gmail.com> ---

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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 _have_

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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: >

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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: > > &

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

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 primiti

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

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

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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 ;-)

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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 >

[PATCH tip/locking/core v4 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

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 <boqun.f...@gmail.com> --- arch/powerpc/include/asm/atomic.h | 116

[PATCH tip/locking/core v4 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers

-by: Boqun Feng <boqun.f...@gmail.com> --- 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

[PATCH tip/locking/core v4 5/6] powerpc: atomic: Implement xchg_* and atomic{, 64}_xchg_* variants

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 <boqun.f...@gmail.com> ---

[PATCH tip/locking/core v4 2/6] atomics: Add test for atomic operations with _relaxed variants

that we can examine their assembly code. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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 83

[PATCH tip/locking/core v4 6/6] powerpc: atomic: Implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants

barriers. Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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

[PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

.au> Cc: <sta...@vger.kernel.org> # 3.4+ Signed-off-by: Boqun Feng <boqun.f...@gmail.com> --- 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 i

[PATCH tip/locking/core v4 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

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) *

Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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: >

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

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 t

  1   2   >