From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Will Deacon <will.deacon@arm.com>, virtualization@lists.linux-foundation.org, "H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org, Ingo Molnar <mingo@kernel.org>, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, Russell King - ARM Linux <linux@arm.linux.org.uk>, user-mode-linux-devel@lists.sourceforge.net, linux-sh@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>, x86@kernel.org, xen-devel@lists.xenproject.org, Ingo Molnar <mingo@elte.hu>, linux-xtensa@linux-xtensa.org, james.hogan@imgtec.com, Arnd Bergmann <arnd@arndb.de>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, adi-buildroot-devel@lists.sourceforge.net, ddaney.cavm@gmail.com, Thomas Gleixner <tglx@linutronix.de>, linux-metag@vger.kernel.orglinux-a Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Date: Thu, 14 Jan 2016 13:29:13 -0800 [thread overview] Message-ID: <20160114212913.GF3818@linux.vnet.ibm.com> (raw) In-Reply-To: <56980C91.1010403@imgtec.com> On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote: > I need some time to understand your test examples. However, Understood. > On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > > > > >The WRC+addr+addr is OK because data dependencies are not required to be > >transitive, in other words, they are not required to flow from one CPU to > >another without the help of an explicit memory barrier. > > I don't see any reliable way to fit WRC+addr+addr into "DATA > DEPENDENCY BARRIERS" section recommendation to have data dependency > barrier between read of a shared pointer/index and read the shared > data based on that pointer. If you have this two reads, it doesn't > matter the rest of scenario, you should put the dependency barrier > in code anyway. If you don't do it in WRC+addr+addr scenario then > after years it can be easily changed to different scenario which > fits some of scenario in "DATA DEPENDENCY BARRIERS" section and > fails. The trick is that lockless_dereference() contains an smp_read_barrier_depends(): #define lockless_dereference(p) \ ({ \ typeof(p) _________p1 = READ_ONCE(p); \ smp_read_barrier_depends(); /* Dependency order vs. p above. */ \ (_________p1); \ }) Or am I missing your point? > > Transitivity is > > Peter Zijlstra recently wrote: "In particular we're very much all > 'confused' about the various notions of transitivity". I am confused > too, so - please use some more simple way to explain your words. > Sorry, but we need a common ground first. OK, how about an example? (Z6.3 in the ppcmem naming scheme.) int x, y, z; void cpu0(void) { WRITE_ONCE(x, 1); smp_wmb(); WRITE_ONCE(y, 1); } void cpu1(void) { WRITE_ONCE(y, 2); smp_wmb(); WRITE_ONCE(z, 1); } void cpu2(void) { r1 = READ_ONCE(z); smp_rmb(); r2 = read_once(x); } If smp_rmb() and smp_wmb() provided transitive ordering, then cpu2() would see cpu0()'s ordering. But they do not, so the ordering is visible at best to the adjacent CPU. This means that the final value of y can be 2, while at the same time r1==1 && r2==0. Now the full barrier, smp_mb(), does provide transitive ordering, so if the three barriers in the above example are replaced with smp_mb() the y==2 && r1==1 && r2==0 outcome will be prohibited. So smp_mb() provides transitivity, as do pairs of smp_store_release() and smp_read_acquire(), as do RCU grace periods. The exact interactions between transitive and non-transitive ordering is a work in progress. That said, if a series of transitive segments ends in a write, which connects to a single non-transitive segment starting with a read, you should be good. And in fact in the example above, you can replace the smp_wmb()s with smp_mb() and leave the smp_rmb() and still prohibit the "cyclic" outcome. If you want a more formal definition, I must refer you back to the ppcmem and herd references. Does that help? Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Cc: Will Deacon <will.deacon@arm.com>, Peter Zijlstra <peterz@infradead.org>, "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>, linux-arch@vger.kernel.org, Andrew Cooper <andrew.cooper3@citrix.com>, Russell King - ARM Linux <linux@arm.linux.org.uk>, virtualization@lists.linux-foundation.org, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>, Joe Perches <joe@perches.com>, David Miller <davem@davemloft.net>, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-metag@vger.kernel.org, linux-mips@linux-mips.org, x86@kernel.org, user-mode-linux-devel@lists.sourceforge.net, adi-buildroot-devel@lists.sourceforge.net, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, xen-devel@lists.xenproject.org, Ralf Baechle <ralf@linux-mips.org>, Ingo Molnar <mingo@kernel.org>, ddaney.cavm@gmail.com, james.hogan@imgtec.com, Michael Ellerman <mpe@ellerman.id.au> Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Date: Thu, 14 Jan 2016 13:29:13 -0800 [thread overview] Message-ID: <20160114212913.GF3818@linux.vnet.ibm.com> (raw) Message-ID: <20160114212913.qWeLG0EZTCwMlQjCWYUkRsm7Pu8AgUNEsVy_hFc41JY@z> (raw) In-Reply-To: <56980C91.1010403@imgtec.com> On Thu, Jan 14, 2016 at 01:01:05PM -0800, Leonid Yegoshin wrote: > I need some time to understand your test examples. However, Understood. > On 01/14/2016 12:34 PM, Paul E. McKenney wrote: > > > > > >The WRC+addr+addr is OK because data dependencies are not required to be > >transitive, in other words, they are not required to flow from one CPU to > >another without the help of an explicit memory barrier. > > I don't see any reliable way to fit WRC+addr+addr into "DATA > DEPENDENCY BARRIERS" section recommendation to have data dependency > barrier between read of a shared pointer/index and read the shared > data based on that pointer. If you have this two reads, it doesn't > matter the rest of scenario, you should put the dependency barrier > in code anyway. If you don't do it in WRC+addr+addr scenario then > after years it can be easily changed to different scenario which > fits some of scenario in "DATA DEPENDENCY BARRIERS" section and > fails. The trick is that lockless_dereference() contains an smp_read_barrier_depends(): #define lockless_dereference(p) \ ({ \ typeof(p) _________p1 = READ_ONCE(p); \ smp_read_barrier_depends(); /* Dependency order vs. p above. */ \ (_________p1); \ }) Or am I missing your point? > > Transitivity is > > Peter Zijlstra recently wrote: "In particular we're very much all > 'confused' about the various notions of transitivity". I am confused > too, so - please use some more simple way to explain your words. > Sorry, but we need a common ground first. OK, how about an example? (Z6.3 in the ppcmem naming scheme.) int x, y, z; void cpu0(void) { WRITE_ONCE(x, 1); smp_wmb(); WRITE_ONCE(y, 1); } void cpu1(void) { WRITE_ONCE(y, 2); smp_wmb(); WRITE_ONCE(z, 1); } void cpu2(void) { r1 = READ_ONCE(z); smp_rmb(); r2 = read_once(x); } If smp_rmb() and smp_wmb() provided transitive ordering, then cpu2() would see cpu0()'s ordering. But they do not, so the ordering is visible at best to the adjacent CPU. This means that the final value of y can be 2, while at the same time r1==1 && r2==0. Now the full barrier, smp_mb(), does provide transitive ordering, so if the three barriers in the above example are replaced with smp_mb() the y==2 && r1==1 && r2==0 outcome will be prohibited. So smp_mb() provides transitivity, as do pairs of smp_store_release() and smp_read_acquire(), as do RCU grace periods. The exact interactions between transitive and non-transitive ordering is a work in progress. That said, if a series of transitive segments ends in a write, which connects to a single non-transitive segment starting with a read, you should be good. And in fact in the example above, you can replace the smp_wmb()s with smp_mb() and leave the smp_rmb() and still prohibit the "cyclic" outcome. If you want a more formal definition, I must refer you back to the ppcmem and herd references. Does that help? Thanx, Paul
next prev parent reply other threads:[~2016-01-14 21:29 UTC|newest] Thread overview: 308+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-10 14:16 [PATCH v3 00/41] arch: barrier cleanup + barriers for virt Michael S. Tsirkin 2016-01-10 14:16 ` Michael S. Tsirkin 2016-01-10 14:16 ` [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin 2016-01-10 14:16 ` Michael S. Tsirkin 2016-01-12 16:28 ` Paul E. McKenney 2016-01-12 16:28 ` Paul E. McKenney 2016-01-12 18:40 ` Michael S. Tsirkin 2016-01-12 18:40 ` Michael S. Tsirkin 2016-01-10 14:16 ` [PATCH v3 02/41] asm-generic: guard smp_store_release/load_acquire Michael S. Tsirkin 2016-01-10 14:16 ` Michael S. Tsirkin 2016-01-10 14:16 ` [PATCH v3 03/41] ia64: rename nop->iosapic_nop Michael S. Tsirkin 2016-01-10 14:16 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 04/41] ia64: reuse asm-generic/barrier.h Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 06/41] s390: " Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 07/41] sparc: " Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 08/41] arm: " Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 09/41] arm64: " Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:17 ` [PATCH v3 10/41] metag: " Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-10 14:18 ` [PATCH v3 11/41] mips: " Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-12 1:14 ` [v3,11/41] " Leonid Yegoshin 2016-01-12 1:14 ` Leonid Yegoshin [not found] ` <56945366.2090504-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> 2016-01-12 8:43 ` Michael S. Tsirkin 2016-01-12 8:43 ` Michael S. Tsirkin 2016-01-12 9:51 ` Peter Zijlstra 2016-01-12 9:51 ` Peter Zijlstra 2016-01-12 9:27 ` Peter Zijlstra 2016-01-12 9:27 ` Peter Zijlstra 2016-01-12 10:25 ` Peter Zijlstra 2016-01-12 10:25 ` Peter Zijlstra 2016-01-12 10:40 ` Peter Zijlstra 2016-01-12 10:40 ` Peter Zijlstra 2016-01-12 11:41 ` Will Deacon 2016-01-12 11:41 ` Will Deacon 2016-01-12 20:45 ` Leonid Yegoshin 2016-01-12 20:45 ` Leonid Yegoshin 2016-01-12 21:40 ` Peter Zijlstra 2016-01-12 21:40 ` Peter Zijlstra 2016-01-13 0:21 ` Leonid Yegoshin 2016-01-13 0:21 ` Leonid Yegoshin 2016-01-13 10:45 ` Will Deacon 2016-01-13 10:45 ` Will Deacon 2016-01-13 19:02 ` Leonid Yegoshin 2016-01-13 19:02 ` Leonid Yegoshin 2016-01-13 20:48 ` Peter Zijlstra 2016-01-13 20:48 ` Peter Zijlstra 2016-01-13 20:58 ` Leonid Yegoshin 2016-01-13 20:58 ` Leonid Yegoshin [not found] ` <5696BA6E.4070508-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> 2016-01-14 12:04 ` Will Deacon 2016-01-14 12:04 ` Will Deacon 2016-01-14 16:16 ` Paul E. McKenney 2016-01-14 16:16 ` Paul E. McKenney 2016-01-14 19:42 ` Leonid Yegoshin 2016-01-14 19:42 ` Leonid Yegoshin 2016-01-14 20:15 ` Peter Zijlstra 2016-01-14 20:15 ` Peter Zijlstra 2016-01-14 20:36 ` Paul E. McKenney 2016-01-14 20:36 ` Paul E. McKenney 2016-01-14 20:46 ` Peter Zijlstra 2016-01-14 20:46 ` Peter Zijlstra 2016-01-14 20:46 ` Leonid Yegoshin 2016-01-14 20:46 ` Leonid Yegoshin 2016-01-14 21:34 ` Paul E. McKenney 2016-01-14 21:34 ` Paul E. McKenney 2016-01-14 21:45 ` Leonid Yegoshin 2016-01-14 21:45 ` Leonid Yegoshin 2016-01-14 22:24 ` Paul E. McKenney 2016-01-14 22:24 ` Paul E. McKenney 2016-01-14 23:04 ` Leonid Yegoshin 2016-01-14 23:04 ` Leonid Yegoshin 2016-01-14 20:12 ` Leonid Yegoshin 2016-01-14 20:12 ` Leonid Yegoshin 2016-01-14 20:48 ` Paul E. McKenney 2016-01-14 20:48 ` Paul E. McKenney 2016-01-14 21:24 ` Leonid Yegoshin 2016-01-14 21:24 ` Leonid Yegoshin 2016-01-14 22:20 ` Paul E. McKenney 2016-01-14 22:20 ` Paul E. McKenney 2016-01-15 9:57 ` Will Deacon 2016-01-15 9:57 ` Will Deacon 2016-01-15 18:54 ` Leonid Yegoshin 2016-01-15 18:54 ` Leonid Yegoshin 2016-01-26 10:24 ` Peter Zijlstra 2016-01-26 10:24 ` Peter Zijlstra 2016-01-26 10:32 ` Peter Zijlstra 2016-01-26 10:32 ` Peter Zijlstra [not found] ` <20160126103200.GI6375-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org> 2016-01-26 11:09 ` Will Deacon 2016-01-26 11:09 ` Will Deacon 2016-01-26 20:11 ` Paul E. McKenney 2016-01-26 20:11 ` Paul E. McKenney 2016-01-27 8:35 ` [PATCH] documentation: Add disclaimer Peter Zijlstra 2016-01-27 8:35 ` Peter Zijlstra 2016-01-27 10:11 ` Will Deacon 2016-01-27 10:11 ` Will Deacon 2016-04-14 21:40 ` Paul E. McKenney 2016-04-14 21:40 ` Paul E. McKenney 2016-01-27 14:57 ` David Howells 2016-01-27 14:57 ` David Howells 2016-01-27 23:35 ` Paul E. McKenney 2016-01-27 23:35 ` Paul E. McKenney 2016-01-28 20:02 ` David Howells 2016-01-28 20:02 ` David Howells [not found] ` <15882.1453906627-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2016-04-14 21:40 ` Paul E. McKenney 2016-04-14 21:40 ` Paul E. McKenney 2016-01-26 19:44 ` [v3,11/41] mips: reuse asm-generic/barrier.h Paul E. McKenney 2016-01-26 19:44 ` Paul E. McKenney 2016-01-18 8:19 ` Herbert Xu 2016-01-18 8:19 ` Herbert Xu 2016-01-18 15:46 ` Paul E. McKenney 2016-01-18 15:46 ` Paul E. McKenney 2016-01-26 16:52 ` Boqun Feng 2016-01-26 16:52 ` Boqun Feng 2016-01-26 17:22 ` Peter Zijlstra 2016-01-26 17:22 ` Peter Zijlstra 2016-01-26 19:44 ` Linus Torvalds 2016-01-26 19:44 ` Linus Torvalds 2016-01-26 20:10 ` Paul E. McKenney 2016-01-26 20:10 ` Paul E. McKenney 2016-01-26 22:15 ` Linus Torvalds 2016-01-26 22:15 ` Linus Torvalds 2016-01-26 22:33 ` Linus Torvalds 2016-01-26 22:33 ` Linus Torvalds 2016-01-26 23:29 ` Paul E. McKenney 2016-01-26 23:29 ` Paul E. McKenney 2016-01-26 23:45 ` Linus Torvalds 2016-01-26 23:45 ` Linus Torvalds 2016-01-27 0:57 ` Paul E. McKenney 2016-01-27 0:57 ` Paul E. McKenney 2016-01-27 2:04 ` Boqun Feng 2016-01-27 2:04 ` Boqun Feng 2016-01-27 23:30 ` Paul E. McKenney 2016-01-27 23:30 ` Paul E. McKenney 2016-01-27 7:51 ` Peter Zijlstra 2016-01-27 7:51 ` Peter Zijlstra 2016-01-27 8:05 ` Linus Torvalds 2016-01-26 19:51 ` Paul E. McKenney 2016-01-26 19:51 ` Paul E. McKenney 2016-01-13 22:26 ` Leonid Yegoshin 2016-01-13 22:26 ` Leonid Yegoshin 2016-01-14 9:24 ` Michael S. Tsirkin 2016-01-14 9:24 ` Michael S. Tsirkin [not found] ` <5696CF08.8080700-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> 2016-01-14 12:14 ` Will Deacon 2016-01-14 12:14 ` Will Deacon 2016-01-14 19:28 ` Leonid Yegoshin 2016-01-14 19:28 ` Leonid Yegoshin 2016-01-14 20:34 ` Paul E. McKenney 2016-01-14 20:34 ` Paul E. McKenney 2016-01-14 21:01 ` Leonid Yegoshin 2016-01-14 21:01 ` Leonid Yegoshin 2016-01-14 21:29 ` Paul E. McKenney [this message] 2016-01-14 21:29 ` Paul E. McKenney 2016-01-14 21:36 ` Leonid Yegoshin 2016-01-14 21:36 ` Leonid Yegoshin 2016-01-14 22:55 ` Paul E. McKenney 2016-01-14 22:55 ` Paul E. McKenney 2016-01-14 23:33 ` Leonid Yegoshin 2016-01-14 23:33 ` Leonid Yegoshin 2016-01-15 0:47 ` Paul E. McKenney 2016-01-15 0:47 ` Paul E. McKenney 2016-01-15 1:07 ` Leonid Yegoshin 2016-01-15 1:07 ` Leonid Yegoshin 2016-01-27 11:26 ` Maciej W. Rozycki 2016-01-27 11:26 ` Maciej W. Rozycki 2016-01-28 0:48 ` Leonid Yegoshin 2016-01-29 13:38 ` Maciej W. Rozycki 2016-01-29 13:38 ` Maciej W. Rozycki 2016-01-28 0:58 ` Leonid Yegoshin 2016-01-28 0:58 ` Leonid Yegoshin [not found] ` <20160115004753.GN3818-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> 2016-01-27 10:40 ` Ralf Baechle 2016-01-27 10:40 ` Ralf Baechle 2016-01-27 12:09 ` Maciej W. Rozycki 2016-01-27 12:09 ` Maciej W. Rozycki 2016-01-15 10:24 ` Will Deacon 2016-01-15 10:24 ` Will Deacon 2016-01-15 17:54 ` Paul E. McKenney 2016-01-15 17:54 ` Paul E. McKenney 2016-01-15 19:28 ` Paul E. McKenney 2016-01-15 19:28 ` Paul E. McKenney 2016-01-25 14:41 ` Will Deacon 2016-01-25 14:41 ` Will Deacon 2016-01-26 1:06 ` Paul E. McKenney 2016-01-26 1:06 ` Paul E. McKenney 2016-01-26 12:10 ` Will Deacon 2016-01-26 12:10 ` Will Deacon 2016-01-26 23:37 ` Paul E. McKenney 2016-01-26 23:37 ` Paul E. McKenney 2016-01-27 10:23 ` Will Deacon 2016-01-27 10:23 ` Will Deacon 2016-01-15 8:55 ` Peter Zijlstra 2016-01-15 8:55 ` Peter Zijlstra 2016-01-15 9:13 ` Peter Zijlstra 2016-01-15 9:13 ` Peter Zijlstra 2016-01-15 17:46 ` Paul E. McKenney 2016-01-15 17:46 ` Paul E. McKenney 2016-01-15 21:27 ` Peter Zijlstra 2016-01-15 21:27 ` Peter Zijlstra 2016-01-15 21:58 ` Paul E. McKenney 2016-01-15 21:58 ` Paul E. McKenney 2016-01-25 16:42 ` Will Deacon 2016-01-25 16:42 ` Will Deacon 2016-01-26 6:03 ` Paul E. McKenney 2016-01-26 6:03 ` Paul E. McKenney 2016-01-26 10:19 ` Peter Zijlstra 2016-01-26 10:19 ` Peter Zijlstra 2016-01-26 20:13 ` Paul E. McKenney 2016-01-26 20:13 ` Paul E. McKenney 2016-01-27 8:39 ` Peter Zijlstra 2016-01-27 8:39 ` Peter Zijlstra 2016-01-26 12:16 ` Will Deacon 2016-01-26 12:16 ` Will Deacon 2016-01-26 14:35 ` Boqun Feng 2016-01-26 14:35 ` Boqun Feng [not found] ` <20160126121608.GE21553-5wv7dgnIgG8@public.gmane.org> 2016-01-26 19:58 ` Paul E. McKenney 2016-01-26 19:58 ` Paul E. McKenney 2016-01-27 10:25 ` Will Deacon 2016-01-27 10:25 ` Will Deacon 2016-01-27 23:32 ` Paul E. McKenney 2016-01-27 23:32 ` Paul E. McKenney 2016-01-15 17:39 ` Paul E. McKenney 2016-01-15 17:39 ` Paul E. McKenney 2016-01-15 21:29 ` Peter Zijlstra 2016-01-15 21:29 ` Peter Zijlstra 2016-01-15 22:01 ` Paul E. McKenney 2016-01-15 22:01 ` Paul E. McKenney 2016-01-25 18:02 ` Will Deacon 2016-01-25 18:02 ` Will Deacon 2016-01-26 6:12 ` Paul E. McKenney 2016-01-26 6:12 ` Paul E. McKenney 2016-01-26 10:15 ` Peter Zijlstra 2016-01-26 10:15 ` Peter Zijlstra 2016-01-10 14:18 ` [PATCH v3 12/41] x86/um: " Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-10 14:18 ` [PATCH v3 13/41] x86: " Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-12 14:10 ` Thomas Gleixner 2016-01-12 14:10 ` Thomas Gleixner 2016-01-10 14:18 ` [PATCH v3 14/41] asm-generic: add __smp_xxx wrappers Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-10 14:18 ` [PATCH v3 15/41] powerpc: define __smp_xxx Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-10 14:18 ` [PATCH v3 16/41] arm64: " Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-10 14:18 ` [PATCH v3 17/41] arm: " Michael S. Tsirkin 2016-01-10 14:18 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 18/41] blackfin: " Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 19/41] ia64: " Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 20/41] metag: " Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 21/41] mips: " Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 22/41] s390: " Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 23/41] sh: define __smp_xxx, fix smp_store_mb for !SMP Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin 2016-01-10 14:19 ` [PATCH v3 24/41] sparc: define __smp_xxx Michael S. Tsirkin 2016-01-10 14:19 ` Michael S. Tsirkin [not found] ` <1452426622-4471-1-git-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-01-10 14:17 ` [PATCH v3 05/41] powerpc: reuse asm-generic/barrier.h Michael S. Tsirkin 2016-01-10 14:17 ` Michael S. Tsirkin 2016-01-12 16:31 ` Paul E. McKenney 2016-01-12 16:31 ` Paul E. McKenney 2016-01-10 14:20 ` [PATCH v3 25/41] tile: define __smp_xxx Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 26/41] xtensa: " Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 27/41] x86: " Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-12 14:11 ` Thomas Gleixner 2016-01-12 14:11 ` Thomas Gleixner 2016-01-10 14:20 ` [PATCH v3 28/41] asm-generic: implement virt_xxx memory barriers Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 29/41] Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb" Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 30/41] virtio_ring: update weak barriers to use virt_xxx Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 31/41] sh: support 1 and 2 byte xchg Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:20 ` [PATCH v3 32/41] sh: move xchg_cmpxchg to a header by itself Michael S. Tsirkin 2016-01-10 14:20 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 33/41] virtio_ring: use virt_store_mb Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 34/41] checkpatch.pl: add missing memory barriers Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 35/41] checkpatch: check for __smp outside barrier.h Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 36/41] checkpatch: add virt barriers Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 37/41] xenbus: use virt_xxx barriers Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 38/41] xen/io: " Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-10 14:21 ` [PATCH v3 39/41] xen/events: " Michael S. Tsirkin 2016-01-10 14:21 ` Michael S. Tsirkin 2016-01-11 11:12 ` David Vrabel 2016-01-11 11:12 ` David Vrabel 2016-01-10 14:22 ` [PATCH v3 40/41] s390: use generic memory barriers Michael S. Tsirkin 2016-01-10 14:22 ` Michael S. Tsirkin 2016-01-10 14:22 ` [PATCH v3 41/41] s390: more efficient smp barriers Michael S. Tsirkin 2016-01-10 14:22 ` Michael S. Tsirkin 2016-01-12 12:50 ` [PATCH v3 00/41] arch: barrier cleanup + barriers for virt Peter Zijlstra 2016-01-12 12:50 ` Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160114212913.GF3818@linux.vnet.ibm.com \ --to=paulmck@linux.vnet.ibm.com \ --cc=Leonid.Yegoshin@imgtec.com \ --cc=adi-buildroot-devel@lists.sourceforge.net \ --cc=arnd@arndb.de \ --cc=ddaney.cavm@gmail.com \ --cc=hpa@zytor.com \ --cc=james.hogan@imgtec.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-metag@vger.kernel.orglinux-a \ --cc=linux-mips@linux-mips.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux-xtensa@linux-xtensa.org \ --cc=linux@arm.linux.org.uk \ --cc=mingo@elte.hu \ --cc=mingo@kernel.org \ --cc=mpe@ellerman.id.au \ --cc=mst@redhat.com \ --cc=peterz@infradead.org \ --cc=sparclinux@vger.kernel.org \ --cc=stefano.stabellini@eu.citrix.com \ --cc=tglx@linutronix.de \ --cc=user-mode-linux-devel@lists.sourceforge.net \ --cc=virtualization@lists.linux-foundation.org \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xenproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).