Groups > linux.kernel > #1244729 > unrolled thread

[PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

Started by	Boqun Feng <boqun.feng@gmail.com>
First post	2015-10-12 16:20 +0200
Last post	2015-10-13 17:50 +0200
Articles	13 on this page of 33 — 6 participants

Back to article view | Back to linux.kernel

  [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
    [PATCH v3 5/6] powerpc: atomic: Implement xchg_* and atomic{,64}_xchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
    [PATCH v3 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
    [PATCH v3 4/6] powerpc: atomic: Implement atomic{,64}_*_return_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
      Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{,64}_*_return_*  variants Will Deacon <will.deacon@arm.com> - 2015-10-13 15:30 +0200
        Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{,64}_*_return_*  variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 15:40 +0200
          Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{,64}_*_return_*  variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-14 03:10 +0200
    [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
      Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Will Deacon <will.deacon@arm.com> - 2015-10-13 15:30 +0200
        Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 16:40 +0200
          Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 16:50 +0200
          Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Will Deacon <will.deacon@arm.com> - 2015-10-13 16:50 +0200
            Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 17:00 +0200
              Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Will Deacon <will.deacon@arm.com> - 2015-10-13 17:10 +0200
                Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 17:50 +0200
                Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-14 03:50 +0200
                  Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and  atomic{,64}_cmpxchg_* variants Will Deacon <will.deacon@arm.com> - 2015-10-14 11:50 +0200
    [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:20 +0200
      Re: [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations  with _relaxed variants Fengguang Wu <lkp@intel.com> - 2015-10-12 17:40 +0200
        Re: [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations  with _relaxed variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 17:50 +0200
          Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic  operations with _relaxed variants Fengguang Wu <lkp@intel.com> - 2015-10-12 18:10 +0200
          Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic  operations with _relaxed variants Fengguang Wu <lkp@intel.com> - 2015-10-12 18:10 +0200
            Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic  operations with _relaxed variants Boqun Feng <boqun.feng@gmail.com> - 2015-10-13 03:40 +0200
    Re: [PATCH v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full  barrier Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:30 +0200
    [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier Boqun Feng <boqun.feng@gmail.com> - 2015-10-12 16:40 +0200
      Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg  a full barrier Michael Ellerman <mpe@ellerman.id.au> - 2015-10-14 02:20 +0200
        Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a  full barrier Boqun Feng <boqun.feng@gmail.com> - 2015-10-14 03:00 +0200
          Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a  full barrier Peter Zijlstra <peterz@infradead.org> - 2015-10-14 10:10 +0200
            Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a  full barrier Boqun Feng <boqun.feng@gmail.com> - 2015-10-14 11:30 +0200
              Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a  full barrier Peter Zijlstra <peterz@infradead.org> - 2015-10-14 11:40 +0200
                Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg  a full barrier Michael Ellerman <mpe@ellerman.id.au> - 2015-10-14 11:50 +0200
    Re: [PATCH v3 0/6] atomics: powerpc: Implement  relaxed/acquire/release variants of some atomics Peter Zijlstra <peterz@infradead.org> - 2015-10-13 14:30 +0200
      Re: [PATCH v3 0/6] atomics: powerpc: Implement  relaxed/acquire/release variants of some atomics "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-13 17:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1244858 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

From	Fengguang Wu <lkp@intel.com>
Date	2015-10-12 18:10 +0200
Subject	Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants
Message-ID	<qiNPI-3X3-13@gated-at.bofh.it>
In reply to	#1244838

> > BTW, does this bot have more tests than 0day? I have pushed this
> > patchset to my own repo and had it tested by 0day.
> 
> Yes, it runs git am, the resulted commits are feed to 0day for
> build/boot/performance tests. If you've already pushed the patches via
> git, the robot should have skip such duplicate tests on the emailed
> patches -- unless there is a bug. I'll have a check.

Ah yes, there is a silly bug.. Fixed, thanks!

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

[toc] | [prev] | [next] | [standalone]

#1244862 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

From	Fengguang Wu <lkp@intel.com>
Date	2015-10-12 18:10 +0200
Subject	Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants
Message-ID	<qiNPI-3X3-15@gated-at.bofh.it>
In reply to	#1244838

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 tree detection is based on the whole patchset's
> > 
> > - subjects
> > - touched files
> > - TO/CC list
> > 
> > Log shows the files and TO/CC are strongly related to powerpc,
> > so it looks a natural choice to apply to it. Especially you put
> > "linuxppc-dev@lists.ozlabs.org" in the TO list while Peter/Ingo
> > in the CC list -- that looks like a strong indication for powerpc.
> > 
> 
> Thank you for your explanation, so how about modifying the title to:
> 
> [PATCH v3 tip/locking/core 2/6] ...
> 
> also works?

Yes it will work -- that'd be the most strong hint.

> BTW, does this bot have more tests than 0day? I have pushed this
> patchset to my own repo and had it tested by 0day.

Yes, it runs git am, the resulted commits are feed to 0day for
build/boot/performance tests. If you've already pushed the patches via
git, the robot should have skip such duplicate tests on the emailed
patches -- unless there is a bug. I'll have a check.

Thanks,
Fengguang

> > [2015-10-12 22:27:49] patched_files: ["arch/powerpc/include/asm/cmpxchg.h", "lib/atomic64_test.c", "include/linux/atomic.h", "arch/powerpc/include/asm/atomic.h"]
> > [2015-10-12 22:27:49] bases: ["powerpc/next", "powerpc/next"]
> > 
> > [2015-10-12 22:27:49] lists: ["linux-kernel@vger.kernel.org", "linuxppc-dev@lists.ozlabs.org", "Peter Zijlstra <peterz@infradead.org>", "Ingo Molnar <mingo@kernel.org>"
> > , "Benjamin Herrenschmidt <benh@kernel.crashing.org>", "Paul Mackerras <paulus@samba.org>", "Michael Ellerman <mpe@ellerman.id.au>", "Thomas Gleixner <tglx@linutronix.d
> > e>", "Will Deacon <will.deacon@arm.com>", "\"Paul E. McKenney\" <paulmck@linux.vnet.ibm.com>", "Waiman Long <waiman.long@hp.com>", "Davidlohr Bueso <dave@stgolabs.net>"
> > , "Boqun Feng <boqun.feng@gmail.com>"]
> > [2015-10-12 22:27:49] bases: ["powerpc/next", "powerpc/next", "powerpc/next", "mpe/next", "mpe/next", "arm64/for-next/core", "arm64/for-next/core"]
> > 
> > The possible improvement would be to let tip:locking/core register
> > itself in the MAINTAINERS file to match files *cmpxchg* *atomic*.
> > 
> > Thanks,
> > Fengguang
> > 
> > On Mon, Oct 12, 2015 at 10:56:52PM +0800, Boqun Feng wrote:
> > > On Mon, Oct 12, 2015 at 10:43:56PM +0800, kbuild test robot wrote:
> > > > Hi Boqun,
> > > > 
> > > > [auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please suggest rules for selecting the more suitable base]
> > > > 
> > > 
> > > This patch should be tested based on current locking/core branch of tip
> > > tree. Thank you.
> > > 
> > > Regards,
> > > Boqun
> > > 
> > > > url:    https://github.com/0day-ci/linux/commits/Boqun-Feng/atomics-powerpc-Implement-relaxed-acquire-release-variants-of-some-atomics/20151012-222750
> > > > config: x86_64-randconfig-x016-10121751 (attached as .config)
> > > > reproduce:
> > > >         # save the attached .config to linux build tree
> > > >         make ARCH=x86_64 
> > > > 
> > > > All error/warnings (new ones prefixed by >>):
> > > > 
> > > >    In file included from include/linux/init.h:4:0,
> > > >                     from lib/atomic64_test.c:14:
> > > >    lib/atomic64_test.c: In function 'test_atomic':
> > > > >> lib/atomic64_test.c:60:9: error: implicit declaration of function 'atomic_inc_return_acquire' [-Werror=implicit-function-declaration]
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >             ^
> > > >    include/linux/compiler.h:166:42: note: in definition of macro 'unlikely'
> > > >     # define unlikely(x) __builtin_expect(!!(x), 0)
> > > >                                              ^
> > > > >> lib/atomic64_test.c:60:2: note: in expansion of macro 'BUG_ON'
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >      ^
> > > > >> lib/atomic64_test.c:38:2: note: in expansion of macro 'TEST_ARGS'
> > > >      test(bit, op##_acquire, ##args); \
> > > >      ^
> > > > >> lib/atomic64_test.c:79:2: note: in expansion of macro 'FAMILY_TEST'
> > > >      FAMILY_TEST(TEST_ARGS, bit, inc_return,  \
> > > >      ^
> > > > >> lib/atomic64_test.c:113:2: note: in expansion of macro 'INC_RETURN_FAMILY_TEST'
> > > >      INC_RETURN_FAMILY_TEST(, v0);
> > > >      ^
> > > > >> lib/atomic64_test.c:60:9: error: implicit declaration of function 'atomic_inc_return_release' [-Werror=implicit-function-declaration]
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >             ^
> > > >    include/linux/compiler.h:166:42: note: in definition of macro 'unlikely'
> > > >     # define unlikely(x) __builtin_expect(!!(x), 0)
> > > >                                              ^
> > > > >> lib/atomic64_test.c:60:2: note: in expansion of macro 'BUG_ON'
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >      ^
> > > >    lib/atomic64_test.c:39:2: note: in expansion of macro 'TEST_ARGS'
> > > >      test(bit, op##_release, ##args); \
> > > >      ^
> > > > >> lib/atomic64_test.c:79:2: note: in expansion of macro 'FAMILY_TEST'
> > > >      FAMILY_TEST(TEST_ARGS, bit, inc_return,  \
> > > >      ^
> > > > >> lib/atomic64_test.c:113:2: note: in expansion of macro 'INC_RETURN_FAMILY_TEST'
> > > >      INC_RETURN_FAMILY_TEST(, v0);
> > > >      ^
> > > > >> lib/atomic64_test.c:60:9: error: implicit declaration of function 'atomic_inc_return_relaxed' [-Werror=implicit-function-declaration]
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >             ^
> > > >    include/linux/compiler.h:166:42: note: in definition of macro 'unlikely'
> > > >     # define unlikely(x) __builtin_expect(!!(x), 0)
> > > >                                              ^
> > > > >> lib/atomic64_test.c:60:2: note: in expansion of macro 'BUG_ON'
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >      ^
> > > >    lib/atomic64_test.c:40:2: note: in expansion of macro 'TEST_ARGS'
> > > >      test(bit, op##_relaxed, ##args); \
> > > >      ^
> > > > >> lib/atomic64_test.c:79:2: note: in expansion of macro 'FAMILY_TEST'
> > > >      FAMILY_TEST(TEST_ARGS, bit, inc_return,  \
> > > >      ^
> > > > >> lib/atomic64_test.c:113:2: note: in expansion of macro 'INC_RETURN_FAMILY_TEST'
> > > >      INC_RETURN_FAMILY_TEST(, v0);
> > > >      ^
> > > > >> lib/atomic64_test.c:60:9: error: implicit declaration of function 'atomic_dec_return_acquire' [-Werror=implicit-function-declaration]
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >             ^
> > > >    include/linux/compiler.h:166:42: note: in definition of macro 'unlikely'
> > > >     # define unlikely(x) __builtin_expect(!!(x), 0)
> > > >                                              ^
> > > > >> lib/atomic64_test.c:60:2: note: in expansion of macro 'BUG_ON'
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >      ^
> > > > >> lib/atomic64_test.c:38:2: note: in expansion of macro 'TEST_ARGS'
> > > >      test(bit, op##_acquire, ##args); \
> > > >      ^
> > > >    lib/atomic64_test.c:85:2: note: in expansion of macro 'FAMILY_TEST'
> > > >      FAMILY_TEST(TEST_ARGS, bit, dec_return,  \
> > > >      ^
> > > > >> lib/atomic64_test.c:114:2: note: in expansion of macro 'DEC_RETURN_FAMILY_TEST'
> > > >      DEC_RETURN_FAMILY_TEST(, v0);
> > > >      ^
> > > > >> lib/atomic64_test.c:60:9: error: implicit declaration of function 'atomic_dec_return_release' [-Werror=implicit-function-declaration]
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >             ^
> > > >    include/linux/compiler.h:166:42: note: in definition of macro 'unlikely'
> > > >     # define unlikely(x) __builtin_expect(!!(x), 0)
> > > >                                              ^
> > > > >> lib/atomic64_test.c:60:2: note: in expansion of macro 'BUG_ON'
> > > >      BUG_ON(atomic##bit##_##op(&v, ##args) != ret);  \
> > > >      ^
> > > >    lib/atomic64_test.c:39:2: note: in expansion of macro 'TEST_ARGS'
> > > >      test(bit, op##_release, ##args); \
> > > >      ^
> > > >    lib/atomic64_test.c:85:2: note: in expansion of macro 'FAMILY_TEST'
> > > >      FAMILY_TEST(TEST_ARGS, bit, dec_return,  \
> > > >      ^
> > > > >> lib/atomic64_test.c:114:2: note: in expansion of macro 'DEC_RETURN_FAMILY_TEST'
> > > >      DEC_RETURN_FAMILY_TEST(, v0);
> > > >      ^
> > > > 
> > > > vim +/atomic_inc_return_acquire +60 lib/atomic64_test.c
> > > > 
> > > >      8	 * the Free Software Foundation; either version 2 of the License, or
> > > >      9	 * (at your option) any later version.
> > > >     10	 */
> > > >     11	
> > > >     12	#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > >     13	
> > > >   > 14	#include <linux/init.h>
> > > >     15	#include <linux/bug.h>
> > > >     16	#include <linux/kernel.h>
> > > >     17	#include <linux/atomic.h>
> > > >     18	
> > > >     19	#define TEST(bit, op, c_op, val)				\
> > > >     20	do {								\
> > > >     21		atomic##bit##_set(&v, v0);				\
> > > >     22		r = v0;							\
> > > >     23		atomic##bit##_##op(val, &v);				\
> > > >     24		r c_op val;						\
> > > >     25		WARN(atomic##bit##_read(&v) != r, "%Lx != %Lx\n",	\
> > > >     26			(unsigned long long)atomic##bit##_read(&v),	\
> > > >     27			(unsigned long long)r);				\
> > > >     28	} while (0)
> > > >     29	
> > > >     30	/*
> > > >     31	 * Test for a atomic operation family,
> > > >     32	 * @test should be a macro accepting parameters (bit, op, ...)
> > > >     33	 */
> > > >     34	
> > > >     35	#define FAMILY_TEST(test, bit, op, args...)	\
> > > >     36	do {						\
> > > >     37		test(bit, op, ##args);		\
> > > >   > 38		test(bit, op##_acquire, ##args);	\
> > > >   > 39		test(bit, op##_release, ##args);	\
> > > >   > 40		test(bit, op##_relaxed, ##args);	\
> > > >     41	} while (0)
> > > >     42	
> > > >     43	#define TEST_RETURN(bit, op, c_op, val)				\
> > > >     44	do {								\
> > > >     45		atomic##bit##_set(&v, v0);				\
> > > >     46		r = v0;							\
> > > >     47		r c_op val;						\
> > > >     48		BUG_ON(atomic##bit##_##op(val, &v) != r);		\
> > > >     49		BUG_ON(atomic##bit##_read(&v) != r);			\
> > > >     50	} while (0)
> > > >     51	
> > > >     52	#define RETURN_FAMILY_TEST(bit, op, c_op, val)			\
> > > >     53	do {								\
> > > >     54		FAMILY_TEST(TEST_RETURN, bit, op, c_op, val);		\
> > > >     55	} while (0)
> > > >     56	
> > > >     57	#define TEST_ARGS(bit, op, init, ret, expect, args...)		\
> > > >     58	do {								\
> > > >     59		atomic##bit##_set(&v, init);				\
> > > >   > 60		BUG_ON(atomic##bit##_##op(&v, ##args) != ret);		\
> > > >     61		BUG_ON(atomic##bit##_read(&v) != expect);		\
> > > >     62	} while (0)
> > > >     63	
> > > >     64	#define XCHG_FAMILY_TEST(bit, init, new)				\
> > > >     65	do {									\
> > > >     66		FAMILY_TEST(TEST_ARGS, bit, xchg, init, init, new, new);	\
> > > >     67	} while (0)
> > > >     68	
> > > >     69	#define CMPXCHG_FAMILY_TEST(bit, init, new, wrong)			\
> > > >     70	do {									\
> > > >     71		FAMILY_TEST(TEST_ARGS, bit, cmpxchg, 				\
> > > >     72				init, init, new, init, new);			\
> > > >     73		FAMILY_TEST(TEST_ARGS, bit, cmpxchg,				\
> > > >     74				init, init, init, wrong, new);			\
> > > >     75	} while (0)
> > > >     76	
> > > >     77	#define INC_RETURN_FAMILY_TEST(bit, i)			\
> > > >     78	do {							\
> > > >   > 79		FAMILY_TEST(TEST_ARGS, bit, inc_return,		\
> > > >     80				i, (i) + one, (i) + one);	\
> > > >     81	} while (0)
> > > >     82	
> > > >     83	#define DEC_RETURN_FAMILY_TEST(bit, i)			\
> > > >     84	do {							\
> > > >   > 85		FAMILY_TEST(TEST_ARGS, bit, dec_return,		\
> > > >     86				i, (i) - one, (i) - one);	\
> > > >     87	} while (0)
> > > >     88	
> > > >     89	static __init void test_atomic(void)
> > > >     90	{
> > > >     91		int v0 = 0xaaa31337;
> > > >     92		int v1 = 0xdeadbeef;
> > > >     93		int onestwos = 0x11112222;
> > > >     94		int one = 1;
> > > >     95	
> > > >     96		atomic_t v;
> > > >     97		int r;
> > > >     98	
> > > >     99		TEST(, add, +=, onestwos);
> > > >    100		TEST(, add, +=, -one);
> > > >    101		TEST(, sub, -=, onestwos);
> > > >    102		TEST(, sub, -=, -one);
> > > >    103		TEST(, or, |=, v1);
> > > >    104		TEST(, and, &=, v1);
> > > >    105		TEST(, xor, ^=, v1);
> > > >    106		TEST(, andnot, &= ~, v1);
> > > >    107	
> > > >    108		RETURN_FAMILY_TEST(, add_return, +=, onestwos);
> > > >    109		RETURN_FAMILY_TEST(, add_return, +=, -one);
> > > >    110		RETURN_FAMILY_TEST(, sub_return, -=, onestwos);
> > > >    111		RETURN_FAMILY_TEST(, sub_return, -=, -one);
> > > >    112	
> > > >  > 113		INC_RETURN_FAMILY_TEST(, v0);
> > > >  > 114		DEC_RETURN_FAMILY_TEST(, v0);
> > > >    115	
> > > >    116		XCHG_FAMILY_TEST(, v0, v1);
> > > >    117		CMPXCHG_FAMILY_TEST(, v0, v1, onestwos);
> > > > 
> > > > ---
> > > > 0-DAY kernel test infrastructure                Open Source Technology Center
> > > > https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> > > 
> > > 
> > 
> > 



> _______________________________________________
> kbuild-all mailing list
> kbuild-all@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all

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

[toc] | [prev] | [next] | [standalone]

#1245265 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

From	Boqun Feng <boqun.feng@gmail.com>
Date	2015-10-13 03:40 +0200
Subject	Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants
Message-ID	<qiWJk-8ld-7@gated-at.bofh.it>
In reply to	#1244862

[Multipart message — attachments visible in raw view] — view raw

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 tree detection is based on the whole patchset's
> > > 
> > > - subjects
> > > - touched files
> > > - TO/CC list
> > > 
> > > Log shows the files and TO/CC are strongly related to powerpc,
> > > so it looks a natural choice to apply to it. Especially you put
> > > "linuxppc-dev@lists.ozlabs.org" in the TO list while Peter/Ingo
> > > in the CC list -- that looks like a strong indication for powerpc.
> > > 
> > 
> > Thank you for your explanation, so how about modifying the title to:
> > 
> > [PATCH v3 tip/locking/core 2/6] ...
> > 
> > also works?
> 
> Yes it will work -- that'd be the most strong hint.
> 

Great! I will use that hint in the future, thank you ;-)

> > BTW, does this bot have more tests than 0day? I have pushed this
> > patchset to my own repo and had it tested by 0day.
> 
> Yes, it runs git am, the resulted commits are feed to 0day for
> build/boot/performance tests. If you've already pushed the patches via
> git, the robot should have skip such duplicate tests on the emailed
> patches -- unless there is a bug. I'll have a check.
> 

Thank you, so I'm not going to resend this v3 patchset, will use the
subject hint for any future patchset ;-)

Regards,
Boqun

[toc] | [prev] | [next] | [standalone]

#1244751 — Re: [PATCH v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier

From	Boqun Feng <boqun.feng@gmail.com>
Date	2015-10-12 16:30 +0200
Subject	Re: [PATCH v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qiMgX-1zC-39@gated-at.bofh.it>
In reply to	#1244729

Oops.. sorry. I will resend this one with correct address list.

On Mon, Oct 12, 2015 at 10:14:01PM +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
> RELEASE+ACQUIRE, which is not a full barrier.
> 
> So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> PPC_ATOMIC_ENTRY_BARRIER and 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").
> 
> Cc: stable@vger.kernel.org # 3.4.y-
> Signed-off-by: Boqun Feng <boqun.feng@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
> index ad6263c..d1a8d93 100644
> --- a/arch/powerpc/include/asm/cmpxchg.h
> +++ b/arch/powerpc/include/asm/cmpxchg.h
> @@ -18,12 +18,12 @@ __xchg_u32(volatile void *p, unsigned long val)
>  	unsigned long prev;
>  
>  	__asm__ __volatile__(
> -	PPC_RELEASE_BARRIER
> +	PPC_ATOMIC_ENTRY_BARRIER
>  "1:	lwarx	%0,0,%2 \n"
>  	PPC405_ERR77(0,%2)
>  "	stwcx.	%3,0,%2 \n\
>  	bne-	1b"
> -	PPC_ACQUIRE_BARRIER
> +	PPC_ATOMIC_EXIT_BARRIER
>  	: "=&r" (prev), "+m" (*(volatile unsigned int *)p)
>  	: "r" (p), "r" (val)
>  	: "cc", "memory");
> @@ -61,12 +61,12 @@ __xchg_u64(volatile void *p, unsigned long val)
>  	unsigned long prev;
>  
>  	__asm__ __volatile__(
> -	PPC_RELEASE_BARRIER
> +	PPC_ATOMIC_ENTRY_BARRIER
>  "1:	ldarx	%0,0,%2 \n"
>  	PPC405_ERR77(0,%2)
>  "	stdcx.	%3,0,%2 \n\
>  	bne-	1b"
> -	PPC_ACQUIRE_BARRIER
> +	PPC_ATOMIC_EXIT_BARRIER
>  	: "=&r" (prev), "+m" (*(volatile unsigned long *)p)
>  	: "r" (p), "r" (val)
>  	: "cc", "memory");
> @@ -151,14 +151,14 @@ __cmpxchg_u32(volatile unsigned int *p, unsigned long old, unsigned long new)
>  	unsigned int prev;
>  
>  	__asm__ __volatile__ (
> -	PPC_RELEASE_BARRIER
> +	PPC_ATOMIC_ENTRY_BARRIER
>  "1:	lwarx	%0,0,%2		# __cmpxchg_u32\n\
>  	cmpw	0,%0,%3\n\
>  	bne-	2f\n"
>  	PPC405_ERR77(0,%2)
>  "	stwcx.	%4,0,%2\n\
>  	bne-	1b"
> -	PPC_ACQUIRE_BARRIER
> +	PPC_ATOMIC_EXIT_BARRIER
>  	"\n\
>  2:"
>  	: "=&r" (prev), "+m" (*p)
> @@ -197,13 +197,13 @@ __cmpxchg_u64(volatile unsigned long *p, unsigned long old, unsigned long new)
>  	unsigned long prev;
>  
>  	__asm__ __volatile__ (
> -	PPC_RELEASE_BARRIER
> +	PPC_ATOMIC_ENTRY_BARRIER
>  "1:	ldarx	%0,0,%2		# __cmpxchg_u64\n\
>  	cmpd	0,%0,%3\n\
>  	bne-	2f\n\
>  	stdcx.	%4,0,%2\n\
>  	bne-	1b"
> -	PPC_ACQUIRE_BARRIER
> +	PPC_ATOMIC_EXIT_BARRIER
>  	"\n\
>  2:"
>  	: "=&r" (prev), "+m" (*p)
> -- 
> 2.5.3
> 
--
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/

[toc] | [prev] | [next] | [standalone]

#1244761 — [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier

From	Boqun Feng <boqun.feng@gmail.com>
Date	2015-10-12 16:40 +0200
Subject	[PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qiMqC-1Ld-37@gated-at.bofh.it>
In reply to	#1244729

According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
versions all need to imply a full barrier, however they are now just
RELEASE+ACQUIRE, which is not a full barrier.

So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and 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").

Cc: <stable@vger.kernel.org> # 3.4.y-
Signed-off-by: Boqun Feng <boqun.feng@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
index ad6263c..d1a8d93 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -18,12 +18,12 @@ __xchg_u32(volatile void *p, unsigned long val)
 	unsigned long prev;
 
 	__asm__ __volatile__(
-	PPC_RELEASE_BARRIER
+	PPC_ATOMIC_ENTRY_BARRIER
 "1:	lwarx	%0,0,%2 \n"
 	PPC405_ERR77(0,%2)
 "	stwcx.	%3,0,%2 \n\
 	bne-	1b"
-	PPC_ACQUIRE_BARRIER
+	PPC_ATOMIC_EXIT_BARRIER
 	: "=&r" (prev), "+m" (*(volatile unsigned int *)p)
 	: "r" (p), "r" (val)
 	: "cc", "memory");
@@ -61,12 +61,12 @@ __xchg_u64(volatile void *p, unsigned long val)
 	unsigned long prev;
 
 	__asm__ __volatile__(
-	PPC_RELEASE_BARRIER
+	PPC_ATOMIC_ENTRY_BARRIER
 "1:	ldarx	%0,0,%2 \n"
 	PPC405_ERR77(0,%2)
 "	stdcx.	%3,0,%2 \n\
 	bne-	1b"
-	PPC_ACQUIRE_BARRIER
+	PPC_ATOMIC_EXIT_BARRIER
 	: "=&r" (prev), "+m" (*(volatile unsigned long *)p)
 	: "r" (p), "r" (val)
 	: "cc", "memory");
@@ -151,14 +151,14 @@ __cmpxchg_u32(volatile unsigned int *p, unsigned long old, unsigned long new)
 	unsigned int prev;
 
 	__asm__ __volatile__ (
-	PPC_RELEASE_BARRIER
+	PPC_ATOMIC_ENTRY_BARRIER
 "1:	lwarx	%0,0,%2		# __cmpxchg_u32\n\
 	cmpw	0,%0,%3\n\
 	bne-	2f\n"
 	PPC405_ERR77(0,%2)
 "	stwcx.	%4,0,%2\n\
 	bne-	1b"
-	PPC_ACQUIRE_BARRIER
+	PPC_ATOMIC_EXIT_BARRIER
 	"\n\
 2:"
 	: "=&r" (prev), "+m" (*p)
@@ -197,13 +197,13 @@ __cmpxchg_u64(volatile unsigned long *p, unsigned long old, unsigned long new)
 	unsigned long prev;
 
 	__asm__ __volatile__ (
-	PPC_RELEASE_BARRIER
+	PPC_ATOMIC_ENTRY_BARRIER
 "1:	ldarx	%0,0,%2		# __cmpxchg_u64\n\
 	cmpd	0,%0,%3\n\
 	bne-	2f\n\
 	stdcx.	%4,0,%2\n\
 	bne-	1b"
-	PPC_ACQUIRE_BARRIER
+	PPC_ATOMIC_EXIT_BARRIER
 	"\n\
 2:"
 	: "=&r" (prev), "+m" (*p)
-- 
2.5.3

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

[toc] | [prev] | [next] | [standalone]

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

From	Michael Ellerman <mpe@ellerman.id.au>
Date	2015-10-14 02:20 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjhXr-5Ve-1@gated-at.bofh.it>
In reply to	#1244761

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
> RELEASE+ACQUIRE, which is not a full barrier.
> 
> So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> PPC_ATOMIC_ENTRY_BARRIER and 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").
> 
> Cc: <stable@vger.kernel.org> # 3.4.y-
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
>  arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)

Hi Boqun,

Thanks for fixing this. In future you should send a patch like this as a
separate patch. I've not been paying attention to it because I assumed it was
part of your full series and was still under discussion like the other patches.

I don't think we've seen any crashes caused by this have we? So I guess I'll
put it in next to let it get some wider testing rather than sending it straight
to Linus.

To be clear you're doing:

> -	PPC_RELEASE_BARRIER
> +	PPC_ATOMIC_ENTRY_BARRIER

Which is correct but doesn't actually change anything at the moment, because
both macros turn into LWSYNC.

On the other hand:

> -	PPC_ACQUIRE_BARRIER
> +	PPC_ATOMIC_EXIT_BARRIER

Is changing an isync (which is then patched to lwsync on some cpus), with a sync.

Also I'm not clear what your stable line means:

> Cc: <stable@vger.kernel.org> # 3.4.y-

Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not
sure if that's the correct syntax either.

cheers

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

[toc] | [prev] | [next] | [standalone]

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

From	Boqun Feng <boqun.feng@gmail.com>
Date	2015-10-14 03:00 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjiAa-6Mx-5@gated-at.bofh.it>
In reply to	#1246221

[Multipart message — attachments visible in raw view] — view raw

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
> > RELEASE+ACQUIRE, which is not a full barrier.
> > 
> > So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> > PPC_ATOMIC_ENTRY_BARRIER and 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").
> > 
> > Cc: <stable@vger.kernel.org> # 3.4.y-
> > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > ---
> >  arch/powerpc/include/asm/cmpxchg.h | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> Hi Boqun,
> 

Hello, Michael

> Thanks for fixing this. In future you should send a patch like this as a
> separate patch. I've not been paying attention to it because I assumed it was

Got it. However, here is the thing, in previous version, this fix
depends on some of other patches in this patchset. So to make this fix
applied cleanly, I reorder my patchset to put this patch first, and the
result is that some of other patches in this patchset depends on
this(they need to remove code modified by this patch).

So I guess I'd better to stop Cc stable for this one, and wait until
this patchset merged and send a separate patch for -stable tree. Does
that work for you? I think this is what Peter want to suggests me to do
when he asked me about this, right, Peter?

> part of your full series and was still under discussion like the other patches.
> 
> I don't think we've seen any crashes caused by this have we? So I guess I'll

No, we haven't seen any.

> put it in next to let it get some wider testing rather than sending it straight
> to Linus.
> 

Good idea, thank you ;-)

> To be clear you're doing:
> 
> > -	PPC_RELEASE_BARRIER
> > +	PPC_ATOMIC_ENTRY_BARRIER
> 
> Which is correct but doesn't actually change anything at the moment, because
> both macros turn into LWSYNC.
> 
> On the other hand:
> 
> > -	PPC_ACQUIRE_BARRIER
> > +	PPC_ATOMIC_EXIT_BARRIER
> 
> Is changing an isync (which is then patched to lwsync on some cpus), with a sync.
> 

These macros are introduced by commit b97021f85517 ("powerpc: Fix
atomic_xxx_return barrier semantics") to fix a similar problem, so I use
them to keep code similar.

> 
> Also I'm not clear what your stable line means:
> 
> > Cc: <stable@vger.kernel.org> # 3.4.y-
> 
> Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not
> sure if that's the correct syntax either.
> 

Quote from Documentation/stable_kernel_rules.txt:

"""
Also, some patches may have kernel version prerequisites.  This can be
specified in the following format in the sign-off area:

     Cc:  <stable@vger.kernel.org> # 3.3.x-

   The tag has the meaning of:
     git cherry-pick <this commit>

   For each "-stable" tree starting with the specified version.
"""

But yes, I have seen several people use like "3.4+", I'm not sure either

Regards,
Boqun

[toc] | [prev] | [next] | [standalone]

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

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-10-14 10:10 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjpii-Uj-1@gated-at.bofh.it>
In reply to	#1246228

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
> > separate patch. I've not been paying attention to it because I assumed it was
> 
> Got it. However, here is the thing, in previous version, this fix
> depends on some of other patches in this patchset. So to make this fix
> applied cleanly, I reorder my patchset to put this patch first, and the
> result is that some of other patches in this patchset depends on
> this(they need to remove code modified by this patch).
> 
> So I guess I'd better to stop Cc stable for this one, and wait until
> this patchset merged and send a separate patch for -stable tree. Does
> that work for you? I think this is what Peter want to suggests me to do
> when he asked me about this, right, Peter?

I don't think I had explicit thoughts about any of that, just that it
might make sense to have this patch not depend on the rest such that it
could indeed be stuffed into stable.

I'll leave the details up to Michael since he's PPC maintainer.
--
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/

[toc] | [prev] | [next] | [standalone]

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

From	Boqun Feng <boqun.feng@gmail.com>
Date	2015-10-14 11:30 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjqxI-2DR-17@gated-at.bofh.it>
In reply to	#1246388

[Multipart message — attachments visible in raw view] — view raw

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
> > > separate patch. I've not been paying attention to it because I assumed it was
> > 
> > Got it. However, here is the thing, in previous version, this fix
> > depends on some of other patches in this patchset. So to make this fix
> > applied cleanly, I reorder my patchset to put this patch first, and the
> > result is that some of other patches in this patchset depends on
> > this(they need to remove code modified by this patch).
> > 
> > So I guess I'd better to stop Cc stable for this one, and wait until
> > this patchset merged and send a separate patch for -stable tree. Does
> > that work for you? I think this is what Peter want to suggests me to do
> > when he asked me about this, right, Peter?
> 
> I don't think I had explicit thoughts about any of that, just that it
> might make sense to have this patch not depend on the rest such that it
> could indeed be stuffed into stable.
> 

Got that. Sorry for misunderstanding you...

> I'll leave the details up to Michael since he's PPC maintainer.

Michael and Peter, rest of this patchset depends on commits which are
currently in the locking/core branch of the tip, so I would like it as a
whole queued there. Besides, I will keep this patch Cc'ed to stable in
future versions, that works for you both?

Regards,
Boqun

[toc] | [prev] | [next] | [standalone]

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

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-10-14 11:40 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjqHo-2OT-19@gated-at.bofh.it>
In reply to	#1246451

On Wed, Oct 14, 2015 at 05:26:53PM +0800, Boqun Feng wrote:
> Michael and Peter, rest of this patchset depends on commits which are
> currently in the locking/core branch of the tip, so I would like it as a
> whole queued there. Besides, I will keep this patch Cc'ed to stable in
> future versions, that works for you both?

From my POV having the Cc stable in there is fine if Michael actually
wants them to go there. GregKH will vacuum them up once they hit Linus'
tree and we don't need to think about it anymore.

Alternatively, Michael could put the patch in a separate branch and we
could both merge that.

Or even, seeing how its a single patch and git mostly does the right
thing, we could just merge it independently in both trees and let git
sort it out at merge time.
--
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/

[toc] | [prev] | [next] | [standalone]

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

From	Michael Ellerman <mpe@ellerman.id.au>
Date	2015-10-14 11:50 +0200
Subject	Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier
Message-ID	<qjqR5-31B-43@gated-at.bofh.it>
In reply to	#1246463

On Wed, 2015-10-14 at 11:33 +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 05:26:53PM +0800, Boqun Feng wrote:
> > Michael and Peter, rest of this patchset depends on commits which are
> > currently in the locking/core branch of the tip, so I would like it as a
> > whole queued there. Besides, I will keep this patch Cc'ed to stable in
> > future versions, that works for you both?
> 
> From my POV having the Cc stable in there is fine if Michael actually
> wants them to go there. GregKH will vacuum them up once they hit Linus'
> tree and we don't need to think about it anymore.

Yeah that's fine by me. Here's an Ack if you want one:

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

> Alternatively, Michael could put the patch in a separate branch and we
> could both merge that.
> 
> Or even, seeing how its a single patch and git mostly does the right
> thing, we could just merge it independently in both trees and let git
> sort it out at merge time.

That probably would work, but I don't think it's necessary.

My tree doesn't get much (or any) more testing than linux-next, so as long as
locking/core is in linux-next then it will be tested just fine that way.

cheers


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

[toc] | [prev] | [next] | [standalone]

#1245668 — Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-10-13 14:30 +0200
Subject	Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics
Message-ID	<qj6Sm-6ug-11@gated-at.bofh.it>
In reply to	#1244729

On Mon, Oct 12, 2015 at 10:14:00PM +0800, Boqun Feng wrote:
 
> The patchset consists of 6 parts:
> 
> 1.	Make xchg, cmpxchg and their atomic_ versions a full barrier
> 
> 2.	Add trivial tests for the new variants in lib/atomic64_test.c
> 
> 3.	Allow architectures to define their own __atomic_op_*() helpers
> 	to build other variants based on relaxed.
> 
> 4.	Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
> 
> 5.	Implement xchg_* and atomic{,64}_xchg_* variants
> 
> 6.	Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
> 
> 
> This patchset is based on current locking/core branch of the tip tree
> and all patches are built and boot tested for little endian pseries, and
> also tested by 0day.
> 

I don't see any immediate problems with this series at this point. Will,
Paul?
--
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/

[toc] | [prev] | [next] | [standalone]

#1245860 — Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

From	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date	2015-10-13 17:50 +0200
Subject	Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics
Message-ID	<qj9ZU-2xR-19@gated-at.bofh.it>
In reply to	#1245668

On Tue, Oct 13, 2015 at 02:27:13PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 12, 2015 at 10:14:00PM +0800, Boqun Feng wrote:
> 
> > The patchset consists of 6 parts:
> > 
> > 1.	Make xchg, cmpxchg and their atomic_ versions a full barrier
> > 
> > 2.	Add trivial tests for the new variants in lib/atomic64_test.c
> > 
> > 3.	Allow architectures to define their own __atomic_op_*() helpers
> > 	to build other variants based on relaxed.
> > 
> > 4.	Implement atomic{,64}_{add,sub,inc,dec}_return_* variants
> > 
> > 5.	Implement xchg_* and atomic{,64}_xchg_* variants
> > 
> > 6.	Implement cmpxchg_* atomic{,64}_cmpxchg_* variants
> > 
> > 
> > This patchset is based on current locking/core branch of the tip tree
> > and all patches are built and boot tested for little endian pseries, and
> > also tested by 0day.
> 
> I don't see any immediate problems with this series at this point. Will,
> Paul?

Every time I have gotten ready to take a close look, someone has pointed
out a problem, and I have deferred until the next version.  Looks like
I should take a close look at Boqun's next version regardless.  ;-)

							Thanx, Paul

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

[PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

Contents

#1244858 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

#1244862 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

#1245265 — Re: [kbuild-all] [lkp] [PATCH v3 2/6] atomics: Add test for atomic operations with _relaxed variants

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

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

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

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

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

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

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

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

#1245668 — Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

#1245860 — Re: [PATCH v3 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

#1244751 — Re: [PATCH v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier

#1244761 — [PATCH RESEND v3 1/6] powerpc: atomic: Make xchg and cmpxchg a full barrier

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

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

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

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

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

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