Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1305571 > unrolled thread
| Started by | "Michael S. Tsirkin" <mst@redhat.com> |
|---|---|
| First post | 2016-01-10 15:20 +0100 |
| Last post | 2016-01-12 14:00 +0100 |
| Articles | 20 on this page of 139 — 13 participants |
Back to article view | Back to linux.kernel
[PATCH v3 00/41] arch: barrier cleanup + barriers for virt "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 06/41] s390: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 13/41] x86: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
Re: [PATCH v3 13/41] x86: reuse asm-generic/barrier.h Thomas Gleixner <tglx@linutronix.de> - 2016-01-12 15:20 +0100
[PATCH v3 08/41] arm: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 21/41] mips: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 03/41] ia64: rename nop->iosapic_nop "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 07/41] sparc: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 15/41] powerpc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 12/41] x86/um: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 22/41] s390: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 11/41] mips: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-12 02:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-12 09:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-12 11:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-12 10:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-12 11:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-12 11:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-12 12:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-12 21:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-12 22:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-13 01:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-13 11:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-13 20:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-13 21:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-13 22:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-14 13:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 18:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 20:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-14 21:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 21:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-14 21:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 21:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 22:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 22:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 23:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-15 00:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 21:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 21:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 22:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 23:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-15 11:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-15 20:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-26 11:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-26 11:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-26 12:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
[PATCH] documentation: Add disclaimer Peter Zijlstra <peterz@infradead.org> - 2016-01-27 09:40 +0100
Re: [PATCH] documentation: Add disclaimer Will Deacon <will.deacon@arm.com> - 2016-01-27 11:20 +0100
Re: [PATCH] documentation: Add disclaimer David Howells <dhowells@redhat.com> - 2016-01-27 16:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Herbert Xu <herbert@gondor.apana.org.au> - 2016-01-18 09:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-18 16:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Boqun Feng <boqun.feng@gmail.com> - 2016-01-26 18:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-26 18:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-26 20:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-26 23:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-26 23:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-27 00:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Linus Torvalds <torvalds@linux-foundation.org> - 2016-01-27 00:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-27 02:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Boqun Feng <boqun.feng@gmail.com> - 2016-01-27 03:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-27 09:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-13 23:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-14 10:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-14 13:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 20:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 21:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 22:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-14 22:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-14 22:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 00:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-15 00:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 01:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> - 2016-01-15 02:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Maciej W. Rozycki" <macro@imgtec.com> - 2016-01-27 12:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Ralf Baechle <ralf@linux-mips.org> - 2016-01-27 11:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Maciej W. Rozycki" <macro@imgtec.com> - 2016-01-27 13:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-15 11:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 19:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 20:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-25 15:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 06:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-26 13:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-27 00:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-27 11:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-15 10:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-15 10:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 19:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-15 22:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 23:00 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-25 17:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 07:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-26 11:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-27 09:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-26 13:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Boqun Feng <boqun.feng@gmail.com> - 2016-01-26 15:40 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-27 11:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 18:50 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-15 22:30 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-15 23:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Will Deacon <will.deacon@arm.com> - 2016-01-25 19:10 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-26 07:20 +0100
Re: [v3,11/41] mips: reuse asm-generic/barrier.h Peter Zijlstra <peterz@infradead.org> - 2016-01-26 11:20 +0100
[PATCH v3 17/41] arm: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 14/41] asm-generic: add __smp_xxx wrappers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 09/41] arm64: reuse asm-generic/barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 18/41] blackfin: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 16/41] arm64: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 20/41] metag: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:20 +0100
[PATCH v3 35/41] checkpatch: check for __smp outside barrier.h "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 38/41] xen/io: use virt_xxx barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 36/41] checkpatch: add virt barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 26/41] xtensa: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 28/41] asm-generic: implement virt_xxx memory barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 37/41] xenbus: use virt_xxx barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 24/41] sparc: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 40/41] s390: use generic memory barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 25/41] tile: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 29/41] Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb" "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 34/41] checkpatch.pl: add missing memory barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 41/41] s390: more efficient smp barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 33/41] virtio_ring: use virt_store_mb "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release() "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
Re: [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-01-12 17:30 +0100
Re: [PATCH v3 01/41] lcoking/barriers, arch: Use smp barriers in smp_store_release() "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-12 19:50 +0100
[PATCH v3 30/41] virtio_ring: update weak barriers to use virt_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 32/41] sh: move xchg_cmpxchg to a header by itself "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 23/41] sh: define __smp_xxx, fix smp_store_mb for !SMP "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
[PATCH v3 27/41] x86: define __smp_xxx "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
Re: [PATCH v3 27/41] x86: define __smp_xxx Thomas Gleixner <tglx@linutronix.de> - 2016-01-12 15:20 +0100
[PATCH v3 39/41] xen/events: use virt_xxx barriers "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
Re: [PATCH v3 39/41] xen/events: use virt_xxx barriers David Vrabel <david.vrabel@citrix.com> - 2016-01-11 12:20 +0100
[PATCH v3 31/41] sh: support 1 and 2 byte xchg "Michael S. Tsirkin" <mst@redhat.com> - 2016-01-10 15:30 +0100
Re: [PATCH v3 00/41] arch: barrier cleanup + barriers for virt Peter Zijlstra <peterz@infradead.org> - 2016-01-12 14:00 +0100
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-14 23:30 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qQYz0-5b5-11@gated-at.bofh.it> |
| In reply to | #1309662 |
On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote:
> On 01/14/2016 12:48 PM, Paul E. McKenney wrote:
> >
> >So SYNC_RMB is intended to implement smp_rmb(), correct?
> Yes.
> >
> >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and
> >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice.
>
> If smp_read_barrier_depends() is used to separate not only two reads
> but read pointer and WRITE basing on that pointer (example below) -
> yes. I just doesn't see any example of this in famous
> Documentation/memory-barriers.txt and had no chance to know what you
> use it in this way too.
Well, Documentation/memory-barriers.txt was intended as a guide for Linux
kernel hackers, and not for hardware architects. The need for something
more precise has become clear over the past year or two, and I am working
on it with some heavy-duty memory-model folks. But all previous memory
models have been for a specific CPU architecture, so doing one for the
intersection of several is offering up some complications. I therefore
cannot yet provide a completion date.
That said, I still suggest use of SYNC_ACQUIRE for read_barrier_depends().
> >The reason for this is that smp_read_barrier_depends() must order the
> >pointer load against any subsequent read or write through a dereference
> >of that pointer.
>
> I can't see that requirement anywhere in Documents directory. I mean
> - the words "write through a dereference of that pointer" or similar
> for smp_read_barrier_depends.
No worries, I will add one. Please see the end of this message for an
initial patch.
Please understand that Documentation/memory-barriers.txt is a living
document:
v4.4: Two changes
v4.3: Three changes
v4.2: Six changes
v4.1: Three changes
v4.0: Two changes
It tends to change as we locate corner cases either in hardware or
in software use cases/APIs.
> > For example:
> >
> > p = READ_ONCE(gp);
> > smp_rmb();
> > r1 = p->a; /* ordered by smp_rmb(). */
> > p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */
> > r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */
> >
> >In contrast:
> >
> > p = READ_ONCE(gp);
> > smp_read_barrier_depends();
> > r1 = p->a; /* ordered by smp_read_barrier_depends(). */
> > p->b = 42; /* ordered by smp_read_barrier_depends(). */
> > r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */
> >
> >Again, if your hardware maintains local ordering for address
> >and data dependencies, you can have read_barrier_depends() and
> >smp_read_barrier_depends() be no-ops like they are for most
> >architectures.
>
> It is not so simple, I mean "local ordering for address and data
> dependencies". Local ordering is NOT enough. It happens that current
> MIPS R6 doesn't require in your example smp_read_barrier_depends()
> but in discussion it comes out that it may not. Because without
> smp_read_barrier_depends() your example can be a part of Will's
> WRC+addr+addr and we found some design which easily can bump into
> this test. And that design actually performs "local ordering for
> address and data dependencies" too.
As noted in another email in this thread, I do not believe that
WRC+addr+addr needs to be prohibited. Sounds like Will and I need to
get our story straight, though.
Will?
Thanx, Paul
------------------------------------------------------------------------
commit 955720966e216b00613fcf60188d507c103f0e80
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Jan 14 14:17:04 2016 -0800
documentation: Subsequent writes ordered by rcu_dereference()
The current memory-barriers.txt does not address the possibility of
a write to a dereferenced pointer. This should be rare, but when it
happens, we need that write -not- to be clobbered by the initialization.
This commit therefore adds an example showing a data dependency ordering
a later data-dependent write.
Reported-by: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index f49c15f7864f..c66ba46d8079 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -555,6 +555,30 @@ between the address load and the data load:
This enforces the occurrence of one of the two implications, and prevents the
third possibility from arising.
+A data-dependency barrier must also order against dependent writes:
+
+ CPU 1 CPU 2
+ =============== ===============
+ { A == 1, B == 2, C = 3, P == &A, Q == &C }
+ B = 4;
+ <write barrier>
+ WRITE_ONCE(P, &B);
+ Q = READ_ONCE(P);
+ <data dependency barrier>
+ *Q = 5;
+
+The data-dependency barrier must order the read into Q with the store
+into *Q. This prohibits this outcome:
+
+ (Q == B) && (B == 4)
+
+Please note that this pattern should be rare. After all, the whole point
+of dependency ordering is to -prevent- writes to the data structure, along
+with the expensive cache misses associated with those writes. This pattern
+can be used to record rare error conditions and the like, and the ordering
+prevents such records from being lost.
+
+
[!] Note that this extremely counterintuitive situation arises most easily on
machines with split caches, so that, for example, one cache bank processes
even-numbered cache lines and the other bank processes odd-numbered cache
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-01-15 11:00 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qR9kK-4iA-19@gated-at.bofh.it> |
| In reply to | #1309708 |
Paul,
On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote:
> > It is not so simple, I mean "local ordering for address and data
> > dependencies". Local ordering is NOT enough. It happens that current
> > MIPS R6 doesn't require in your example smp_read_barrier_depends()
> > but in discussion it comes out that it may not. Because without
> > smp_read_barrier_depends() your example can be a part of Will's
> > WRC+addr+addr and we found some design which easily can bump into
> > this test. And that design actually performs "local ordering for
> > address and data dependencies" too.
>
> As noted in another email in this thread, I do not believe that
> WRC+addr+addr needs to be prohibited. Sounds like Will and I need to
> get our story straight, though.
I think you figured this out while I was sleeping, but just to confirm:
1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only
to memory accesses appearing in *program-order* before the SYNC
2. We need WRC+sync+addr to work, which means that the SYNC in P1 must
also capture the store in P0 as being "before" the barrier. Leonid
reckons it works, but his explanation [2] focussed on the address
dependency in P2 as to why this works. If that is the case (i.e.
address dependency provides global transitivity), then WRC+addr+addr
should also work (even though its not required).
3. It seems that WRC+addr+addr doesn't work, so I'm still suspicious
about WRC+sync+addr, because neither the architecture document or
Leonid's explanation tell me that it should be forbidden.
Will
[1] https://imgtec.com/?do-download=4302
[2] http://lkml.kernel.org/r/569565DA.2010903@imgtec.com (scroll to the end)
[toc] | [prev] | [next] | [standalone]
| From | Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> |
|---|---|
| Date | 2016-01-15 20:00 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qRhLk-1DX-9@gated-at.bofh.it> |
| In reply to | #1310008 |
On 01/15/2016 01:57 AM, Will Deacon wrote: > Paul, > > > I think you figured this out while I was sleeping, but just to confirm: > > 1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only > to memory accesses appearing in *program-order* before the SYNC > > 2. We need WRC+sync+addr to work, which means that the SYNC in P1 must > also capture the store in P0 as being "before" the barrier. Leonid > reckons it works, but his explanation [2] focussed on the address > dependency in P2 as to why this works. If that is the case (i.e. > address dependency provides global transitivity), then WRC+addr+addr > should also work (even though its not required). No, it is not correct. There is one old design which provides access to core (thread0 + thread1) write-buffers for threads load in advance of it is visible to other cores. It means, that WRC+sync+addr passes because of SYNC in write thread and register dependency inside other thread but WRC+addr+addr may fail because other core may get a stale data. > > 3. It seems that WRC+addr+addr doesn't work, so I'm still suspicious > about WRC+sync+addr, because neither the architecture document or > Leonid's explanation tell me that it should be forbidden. > > Will > > [1] https://imgtec.com/?do-download=4302 > [2] http://lkml.kernel.org/r/569565DA.2010903@imgtec.com (scroll to the end)
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-01-26 11:30 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qV92Q-2Ih-73@gated-at.bofh.it> |
| In reply to | #1309708 |
On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > If smp_read_barrier_depends() is used to separate not only two reads > > but read pointer and WRITE basing on that pointer (example below) - > > yes. I just doesn't see any example of this in famous > > Documentation/memory-barriers.txt and had no chance to know what you > > use it in this way too. > > Well, Documentation/memory-barriers.txt was intended as a guide for Linux > kernel hackers, and not for hardware architects. Yeah, this goes under the header: memory-barriers.txt is _NOT_ a specification (I seem to keep repeating this). > ------------------------------------------------------------------------ > > commit 955720966e216b00613fcf60188d507c103f0e80 > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > Date: Thu Jan 14 14:17:04 2016 -0800 > > documentation: Subsequent writes ordered by rcu_dereference() > > The current memory-barriers.txt does not address the possibility of > a write to a dereferenced pointer. This should be rare, How are these rare? Isn't: rcu_read_lock() obj = rcu_dereference(ptr); if (!atomic_inc_not_zero(&obj->ref)) obj = NULL; rcu_read_unlock(); a _very_ common thing to do?
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-01-26 11:40 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qV9cu-2Od-23@gated-at.bofh.it> |
| In reply to | #1317719 |
On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote:
> Yeah, this goes under the header: memory-barriers.txt is _NOT_ a
> specification (I seem to keep repeating this).
Do we want this ?
---
Documentation/memory-barriers.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a61be39c7b51..433326ebdc26 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1,3 +1,4 @@
+
============================
LINUX KERNEL MEMORY BARRIERS
============================
@@ -5,6 +6,22 @@
By: David Howells <dhowells@redhat.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+==========
+DISCLAIMER
+==========
+
+This document is not a specification; it is intentionally (for the sake of
+brevity) and unintentionally (due to being human) incomplete. This document is
+meant as a guide to using the various memory barriers provided by Linux, but
+in case of any doubt (and there are many) please ask.
+
+I repeat, this document is not a specification of what Linux expects from
+hardware.
+
+=====
+INDEX
+=====
+
Contents:
(*) Abstract memory access model.
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-01-26 12:10 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qV9Fw-3em-7@gated-at.bofh.it> |
| In reply to | #1317725 |
On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > specification (I seem to keep repeating this). > > Do we want this ? > > --- > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index a61be39c7b51..433326ebdc26 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -1,3 +1,4 @@ > + > ============================ > LINUX KERNEL MEMORY BARRIERS > ============================ > @@ -5,6 +6,22 @@ > By: David Howells <dhowells@redhat.com> > Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > +========== > +DISCLAIMER > +========== > + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document is > +meant as a guide to using the various memory barriers provided by Linux, but > +in case of any doubt (and there are many) please ask. It might be worth adding you and me to the top of the file, to save Paul Cc'ing us on questions (get_maintainer.pl points at poor old Corbet for this file). But yes, it seems that something like this is required. Will
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-26 23:10 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVjYe-2hg-23@gated-at.bofh.it> |
| In reply to | #1317740 |
On Tue, Jan 26, 2016 at 11:09:27AM +0000, Will Deacon wrote: > On Tue, Jan 26, 2016 at 11:32:00AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > > > > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > > > specification (I seem to keep repeating this). > > > > Do we want this ? Seems likely to me. ;-) > > --- > > Documentation/memory-barriers.txt | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > index a61be39c7b51..433326ebdc26 100644 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -1,3 +1,4 @@ > > + > > ============================ > > LINUX KERNEL MEMORY BARRIERS > > ============================ > > @@ -5,6 +6,22 @@ > > By: David Howells <dhowells@redhat.com> > > Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > > > +========== > > +DISCLAIMER > > +========== > > + > > +This document is not a specification; it is intentionally (for the sake of > > +brevity) and unintentionally (due to being human) incomplete. This document is > > +meant as a guide to using the various memory barriers provided by Linux, but > > +in case of any doubt (and there are many) please ask. > > It might be worth adding you and me to the top of the file, to save Paul > Cc'ing us on questions (get_maintainer.pl points at poor old Corbet for > this file). > > But yes, it seems that something like this is required. So Peter, would you like to update your patch to include yourself and Will as authors? Thanx, Paul
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-01-27 09:40 +0100 |
| Subject | [PATCH] documentation: Add disclaimer |
| Message-ID | <qVtNU-J7-9@gated-at.bofh.it> |
| In reply to | #1318438 |
On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote:
> So Peter, would you like to update your patch to include yourself
> and Will as authors?
Sure, here goes.
---
Subject: documentation: Add disclaimer
It appears people are reading this document as a requirements list for
building hardware. This is not the intent of this document. Nor is it
particularly suited for this purpose.
The primary purpose of this document is our collective attempt to define
a set of primitives that (hopefully) allow us to write correct code on
the myriad of SMP platforms Linux supports.
Its a definite work in progress as our understanding of these platforms,
and memory ordering in general, progresses.
Nor does being mentioned in this document mean we think its a
particularly good idea; the data dependency barrier required by Alpha
being a prime example. Yes we have it, no you're insane to require it
when building new hardware.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
Documentation/memory-barriers.txt | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a61be39c7b51..98626125f484 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -4,8 +4,24 @@
By: David Howells <dhowells@redhat.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+ Will Deacon <will.deacon@arm.com>
+ Peter Zijlstra <peterz@infradead.org>
-Contents:
+==========
+DISCLAIMER
+==========
+
+This document is not a specification; it is intentionally (for the sake of
+brevity) and unintentionally (due to being human) incomplete. This document is
+meant as a guide to using the various memory barriers provided by Linux, but
+in case of any doubt (and there are many) please ask.
+
+I repeat, this document is not a specification of what Linux expects from
+hardware.
+
+========
+CONTENTS
+========
(*) Abstract memory access model.
[toc] | [prev] | [next] | [standalone]
| From | Will Deacon <will.deacon@arm.com> |
|---|---|
| Date | 2016-01-27 11:20 +0100 |
| Subject | Re: [PATCH] documentation: Add disclaimer |
| Message-ID | <qVvmG-1Z6-27@gated-at.bofh.it> |
| In reply to | #1318750 |
On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote: > On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote: > > So Peter, would you like to update your patch to include yourself > > and Will as authors? > > Sure, here goes. > > --- > Subject: documentation: Add disclaimer > > It appears people are reading this document as a requirements list for > building hardware. This is not the intent of this document. Nor is it > particularly suited for this purpose. > > The primary purpose of this document is our collective attempt to define > a set of primitives that (hopefully) allow us to write correct code on > the myriad of SMP platforms Linux supports. > > Its a definite work in progress as our understanding of these platforms, > and memory ordering in general, progresses. > > Nor does being mentioned in this document mean we think its a > particularly good idea; the data dependency barrier required by Alpha > being a prime example. Yes we have it, no you're insane to require it > when building new hardware. > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > --- > Documentation/memory-barriers.txt | 18 +++++++++++++++++- > 1 file changed, 17 insertions(+), 1 deletion(-) Acked-by: Will Deacon <will.deacon@arm.com> Will
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2016-01-27 16:00 +0100 |
| Subject | Re: [PATCH] documentation: Add disclaimer |
| Message-ID | <qVzJE-4Zj-19@gated-at.bofh.it> |
| In reply to | #1318750 |
Peter Zijlstra <peterz@infradead.org> wrote:
> +==========
> +DISCLAIMER
> +==========
> +
> +This document is not a specification; it is intentionally (for the sake of
> +brevity) and unintentionally (due to being human) incomplete. This document is
> +meant as a guide to using the various memory barriers provided by Linux, but
> +in case of any doubt (and there are many) please ask.
> +
> +I repeat, this document is not a specification of what Linux expects from
> +hardware.
The purpose of this document is twofold:
(1) to specify the minimum functionality that one can rely on for any
particular barrier, and
(2) to provide a guide as to how to use the barriers that are available.
Note that an architecture can provide more than the minimum requirement for
any particular barrier, but if the barrier provides less than that, it is
incorrect.
Note also that it is possible that a barrier may be a no-op for an
architecture because the way that arch works renders an explicit barrier
unnecessary in that case.
> +
Can you bung an extra blank line in here if you have to redo this at all?
> +========
> +CONTENTS
> +========
>
> (*) Abstract memory access model.
>
David
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-26 23:10 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVjYe-2hg-19@gated-at.bofh.it> |
| In reply to | #1317719 |
On Tue, Jan 26, 2016 at 11:24:02AM +0100, Peter Zijlstra wrote: > On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > > Yes. > > > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > > > If smp_read_barrier_depends() is used to separate not only two reads > > > but read pointer and WRITE basing on that pointer (example below) - > > > yes. I just doesn't see any example of this in famous > > > Documentation/memory-barriers.txt and had no chance to know what you > > > use it in this way too. > > > > Well, Documentation/memory-barriers.txt was intended as a guide for Linux > > kernel hackers, and not for hardware architects. > > Yeah, this goes under the header: memory-barriers.txt is _NOT_ a > specification (I seem to keep repeating this). > > > ------------------------------------------------------------------------ > > > > commit 955720966e216b00613fcf60188d507c103f0e80 > > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com> > > Date: Thu Jan 14 14:17:04 2016 -0800 > > > > documentation: Subsequent writes ordered by rcu_dereference() > > > > The current memory-barriers.txt does not address the possibility of > > a write to a dereferenced pointer. This should be rare, > > How are these rare? Isn't: > > rcu_read_lock() > obj = rcu_dereference(ptr); > if (!atomic_inc_not_zero(&obj->ref)) > obj = NULL; > rcu_read_unlock(); > > a _very_ common thing to do? It is, but it provides its own barriers, so does not need to rely on dependency ordering. Thanx, Paul
[toc] | [prev] | [next] | [standalone]
| From | Herbert Xu <herbert@gondor.apana.org.au> |
|---|---|
| Date | 2016-01-18 09:30 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qSdmi-6qu-9@gated-at.bofh.it> |
| In reply to | #1309643 |
Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For example: > > p = READ_ONCE(gp); > smp_rmb(); > r1 = p->a; /* ordered by smp_rmb(). */ > p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */ > r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */ > > In contrast: > > p = READ_ONCE(gp); > smp_read_barrier_depends(); > r1 = p->a; /* ordered by smp_read_barrier_depends(). */ > p->b = 42; /* ordered by smp_read_barrier_depends(). */ > r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */ > > Again, if your hardware maintains local ordering for address > and data dependencies, you can have read_barrier_depends() and > smp_read_barrier_depends() be no-ops like they are for most > architectures. > > Does that help? This is crazy! smp_rmb started out being strictly stronger than smp_read_barrier_depends, when did this stop being the case? -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-18 16:50 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qSke6-2DG-11@gated-at.bofh.it> |
| In reply to | #1311370 |
On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > The reason for this is that smp_read_barrier_depends() must order the > > pointer load against any subsequent read or write through a dereference > > of that pointer. For example: > > > > p = READ_ONCE(gp); > > smp_rmb(); > > r1 = p->a; /* ordered by smp_rmb(). */ > > p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */ > > r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */ > > > > In contrast: > > > > p = READ_ONCE(gp); > > smp_read_barrier_depends(); > > r1 = p->a; /* ordered by smp_read_barrier_depends(). */ > > p->b = 42; /* ordered by smp_read_barrier_depends(). */ > > r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */ > > > > Again, if your hardware maintains local ordering for address > > and data dependencies, you can have read_barrier_depends() and > > smp_read_barrier_depends() be no-ops like they are for most > > architectures. > > > > Does that help? > > This is crazy! smp_rmb started out being strictly stronger than > smp_read_barrier_depends, when did this stop being the case? Hello, Herbert! It is true that most Linux kernel code relies only on the read-read properties of dependencies, but the read-write properties are useful. Admittedly relatively rarely, but useful. The better comparison for smp_read_barrier_depends(), especially in its rcu_dereference*() form, is smp_load_acquire(). Thanx, Paul
[toc] | [prev] | [next] | [standalone]
| From | Boqun Feng <boqun.feng@gmail.com> |
|---|---|
| Date | 2016-01-26 18:00 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVf8f-6St-27@gated-at.bofh.it> |
| In reply to | #1311621 |
[Multipart message — attachments visible in raw view] — view raw
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 <paulmck@linux.vnet.ibm.com> wrote: > > > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > The reason for this is that smp_read_barrier_depends() must order the > > > pointer load against any subsequent read or write through a dereference > > > of that pointer. For example: > > > > > > p = READ_ONCE(gp); > > > smp_rmb(); > > > r1 = p->a; /* ordered by smp_rmb(). */ > > > p->b = 42; /* NOT ordered by smp_rmb(), BUG!!! */ > > > r2 = x; /* ordered by smp_rmb(), but doesn't need to be. */ > > > > > > In contrast: > > > > > > p = READ_ONCE(gp); > > > smp_read_barrier_depends(); > > > r1 = p->a; /* ordered by smp_read_barrier_depends(). */ > > > p->b = 42; /* ordered by smp_read_barrier_depends(). */ > > > r2 = x; /* not ordered by smp_read_barrier_depends(), which is OK. */ > > > > > > Again, if your hardware maintains local ordering for address > > > and data dependencies, you can have read_barrier_depends() and > > > smp_read_barrier_depends() be no-ops like they are for most > > > architectures. > > > > > > Does that help? > > > > This is crazy! smp_rmb started out being strictly stronger than > > smp_read_barrier_depends, when did this stop being the case? > > Hello, Herbert! > > It is true that most Linux kernel code relies only on the read-read > properties of dependencies, but the read-write properties are useful. > Admittedly relatively rarely, but useful. > > The better comparison for smp_read_barrier_depends(), especially in > its rcu_dereference*() form, is smp_load_acquire(). > Confused.. I recall that last time you and Linus came into a conclusion that even on Alpha, a barrier for read->write with data dependency is unnecessary: http://article.gmane.org/gmane.linux.kernel/2077661 And in an earlier mail of that thread, Linus made his point that smp_read_barrier_depends() should only be used to order read->read. So right now, are we going to extend the semantics of smp_read_barrier_depends()? Can we just make smp_read_barrier_depends() still only work for read->read, and assume all the architectures won't reorder read->write with data dependency, so that the code above having a smp_rmb() also works? Regards, Boqun
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-01-26 18:30 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVfBh-7mT-23@gated-at.bofh.it> |
| In reply to | #1318145 |
On Wed, Jan 27, 2016 at 12:52:07AM +0800, Boqun Feng wrote: > I recall that last time you and Linus came into a conclusion that even > on Alpha, a barrier for read->write with data dependency is unnecessary: > > http://article.gmane.org/gmane.linux.kernel/2077661 > > And in an earlier mail of that thread, Linus made his point that > smp_read_barrier_depends() should only be used to order read->read. > > So right now, are we going to extend the semantics of > smp_read_barrier_depends()? Can we just make smp_read_barrier_depends() > still only work for read->read, and assume all the architectures won't > reorder read->write with data dependency, so that the code above having > a smp_rmb() also works? That discussions was about control dependencies. So writes that _depend_ on a prior read having an explicit value. So something like: struct foo *x = READ_ONCE(*ptr); smp_read_barrier_depends() if (x->val == 5) x->bar = 5; In that case, the load of x->val must be complete and its value determined _before_ the store to x->bar can happen. This is distinct from: struct foo *x = READ_ONCE(*ptr); smp_read_barrier_depends(); x->bar = 5; And its the second case where smp_read_barrier_depends() read->write order matters.
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-01-26 20:50 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVhMK-qV-7@gated-at.bofh.it> |
| In reply to | #1318193 |
On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> This is distinct from:
That may be distinct, but:
> struct foo *x = READ_ONCE(*ptr);
> smp_read_barrier_depends();
> x->bar = 5;
This case is complete BS. Stop perpetuating it. I already removed a
number of bogus cases of it, and I removed the incorrect documentation
that had this crap.
It's called "smp_READ_barrier_depends()" for a reason.
Alpha is the only one that needs it, and alpha needs it only for
dependent READS.
It's not called smp_read_write_barrier_depends(). It's not called
"smp_mb_depends()". It's a weaker form of "smp_rmb()", nothing else.
So alpha does have an implied dependency chain from a read to a
subsequent dependent write, and does not need any extra barriers.
Alpha does *not* have a dependency chain from a read to a subsequent
read, which is why we need that horrible crappy
smp_read_barrier_depends(). But it's the only reason.
This is the alpha reference manual wrt read-to-write dependency:
5.6.1.7 Definition of Dependence Constraint
The depends relation (DP) is defined as follows. Given u and v
issued by processor Pi, where u
is a read or an instruction fetch and v is a write, u precedes v
in DP order (written u DP v, that
is, v depends on u) in either of the following situations:
• u determines the execution of v, the location accessed by v, or
the value written by v.
• u determines the execution or address or value of another
memory access z that precedes
v or might precede v (that is, would precede v in some execution
path depending
on the value read by u) by processor issue constraint (see Section 5.6.1.3).
Note that the dependence barrier honors not only control flow, but
address and data values too. This is a different syntax than we use,
but 'u' is the READ_ONCE, and 'v' is the write. Any data, address or
conditional dependency between the two implies an ordering.
So no, "smp_read_barrier_depends()" is *ONLY* about two reads, where
the second read is data-dependent on the first. Nothing else.
So if you _ever_ see a "smp_read_barrier_depends()" that isn't about a
barrier between two reads, then that is a bug.
The above code is crap. It's exactly as much crap as
a = READ_ONCE(x);
smp_rmb();
WRITE_ONCE(b, y);
because a "rmb()" simply doesn't have anything to do with
read-vs-subsequent-write ordering.
Linus
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-26 23:10 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVjYf-2hg-31@gated-at.bofh.it> |
| In reply to | #1318319 |
On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > > > This is distinct from: > > That may be distinct, but: > > > struct foo *x = READ_ONCE(*ptr); > > smp_read_barrier_depends(); > > x->bar = 5; > > This case is complete BS. Stop perpetuating it. I already removed a > number of bogus cases of it, and I removed the incorrect documentation > that had this crap. If I understand your objection correctly, you want the above pattern expressed either like this: struct foo *x = rcu_dereference(*ptr); x->bar = 5; Or like this: struct foo *x = lockless_dereference(*ptr); x->bar = 5; Or am I missing your point? > It's called "smp_READ_barrier_depends()" for a reason. > > Alpha is the only one that needs it, and alpha needs it only for > dependent READS. > > It's not called smp_read_write_barrier_depends(). It's not called > "smp_mb_depends()". It's a weaker form of "smp_rmb()", nothing else. > > So alpha does have an implied dependency chain from a read to a > subsequent dependent write, and does not need any extra barriers. > > Alpha does *not* have a dependency chain from a read to a subsequent > read, which is why we need that horrible crappy > smp_read_barrier_depends(). But it's the only reason. > > This is the alpha reference manual wrt read-to-write dependency: > > 5.6.1.7 Definition of Dependence Constraint > > The depends relation (DP) is defined as follows. Given u and v > issued by processor Pi, where u > is a read or an instruction fetch and v is a write, u precedes v > in DP order (written u DP v, that > is, v depends on u) in either of the following situations: > > • u determines the execution of v, the location accessed by v, or > the value written by v. > • u determines the execution or address or value of another > memory access z that precedes > > v or might precede v (that is, would precede v in some execution > path depending > on the value read by u) by processor issue constraint (see Section 5.6.1.3). > > Note that the dependence barrier honors not only control flow, but > address and data values too. This is a different syntax than we use, > but 'u' is the READ_ONCE, and 'v' is the write. Any data, address or > conditional dependency between the two implies an ordering. > > So no, "smp_read_barrier_depends()" is *ONLY* about two reads, where > the second read is data-dependent on the first. Nothing else. > > So if you _ever_ see a "smp_read_barrier_depends()" that isn't about a > barrier between two reads, then that is a bug. And the smp_read_barrier_depends() in both rcu_dereference() and in lockless_dereference() is ordering the read-to-read case and the underlying hardware is ordering the read-to-write case on weakly ordered hardware. Or, again, am I missing your point? Thanx, Paul > The above code is crap. It's exactly as much crap as > > a = READ_ONCE(x); > smp_rmb(); > WRITE_ONCE(b, y); > > because a "rmb()" simply doesn't have anything to do with > read-vs-subsequent-write ordering. > > Linus >
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-01-26 23:20 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVk7U-2la-9@gated-at.bofh.it> |
| In reply to | #1318439 |
On Tue, Jan 26, 2016 at 12:10 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote:
>>
>> > struct foo *x = READ_ONCE(*ptr);
>> > smp_read_barrier_depends();
>> > x->bar = 5;
>>
>> This case is complete BS. Stop perpetuating it. I already removed a
>> number of bogus cases of it, and I removed the incorrect documentation
>> that had this crap.
>
> If I understand your objection correctly, you want the above pattern
> expressed either like this:
>
> struct foo *x = rcu_dereference(*ptr);
> x->bar = 5;
>
> Or like this:
>
> struct foo *x = lockless_dereference(*ptr);
> x->bar = 5;
>
> Or am I missing your point?
You are entirely missing the point.
You might as well just write it as
struct foo x = READ_ONCE(*ptr);
x->bar = 5;
because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
So what I am saying is simple: anybody who writes that
"smp_read_barrier_depends()" in there is just ttoally and completely
WRONG, and the fact that Peter wrote it out after I removed several
instances of that bloody f*cking idiocy is disturbing.
Don't do it. It's BS. It's wrong. Don't make excuses for it.
Linus
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2016-01-26 23:40 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVkrg-2uO-25@gated-at.bofh.it> |
| In reply to | #1318442 |
On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> You might as well just write it as
>
> struct foo x = READ_ONCE(*ptr);
> x->bar = 5;
>
> because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
Just to clarify: on alpha it adds a memory barrier, but that memory
barrier is useless.
On non-alpha, it is a no-op, and obviously does nothing simply because
it generates no code.
So if anybody believes that the "smp_read_barrier_depends()" does
something, they are *wrong*.
And if anybody sends out an email with that smp_read_barrier_depends()
in an example, they are actively just confusing other people, which is
even worse than just being wrong. Which is why I jumped in.
So stop perpetuating the myth that smp_read_barrier_depends() does
something here. It does not. It's a bug, and it has become this "mind
virus" for some people that seem to believe that it does something.
I had to remove this crap once from the kernel already, see commit
105ff3cbf225 ("atomic: remove all traces of READ_ONCE_CTRL() and
atomic*_read_ctrl()").
I don't want to ever see that broken construct again. And I want to
make sure that everybody is educated about how broken it was. I'm
extremely unhappy that it came up again.
If it turns out that some architecture does actually need a barrier
between a read and a dependent write, then that will mean that
(a) we'll have to make up a _new_ barrier, because
"smp_read_barrier_depends()" is not that barrier. We'll presumably
then have to make that new barrier part of "rcu_derefence()" and
friends.
(b) we will have found an architecture with even worse memory
ordering semantics than alpha, and we'll have to stop castigating
alpha for being the worst memory ordering ever.
but I sincerely hope that we'll never find that kind of broken architecture.
Linus
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-01-27 00:30 +0100 |
| Subject | Re: [v3,11/41] mips: reuse asm-generic/barrier.h |
| Message-ID | <qVldF-33s-19@gated-at.bofh.it> |
| In reply to | #1318448 |
On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote:
> On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > You might as well just write it as
> >
> > struct foo x = READ_ONCE(*ptr);
> > x->bar = 5;
> >
> > because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
>
> Just to clarify: on alpha it adds a memory barrier, but that memory
> barrier is useless.
No trailing data-dependent read, so agreed, no smp_read_barrier_depends()
needed. That said, I believe that we should encourage rcu_dereference*()
or lockless_dereference() instead of READ_ONCE() for documentation
reasons, though.
> On non-alpha, it is a no-op, and obviously does nothing simply because
> it generates no code.
>
> So if anybody believes that the "smp_read_barrier_depends()" does
> something, they are *wrong*.
The other problem with smp_read_barrier_depends() is that it is often
a pain figuring out which prior load it is supposed to apply to.
Hence my preference for rcu_dereference*() and lockless_dereference().
> And if anybody sends out an email with that smp_read_barrier_depends()
> in an example, they are actively just confusing other people, which is
> even worse than just being wrong. Which is why I jumped in.
>
> So stop perpetuating the myth that smp_read_barrier_depends() does
> something here. It does not. It's a bug, and it has become this "mind
> virus" for some people that seem to believe that it does something.
It looks like I should add words to memory-barriers.txt de-emphasizing
smp_read_barrier_depends(). I will take a look at that.
> I had to remove this crap once from the kernel already, see commit
> 105ff3cbf225 ("atomic: remove all traces of READ_ONCE_CTRL() and
> atomic*_read_ctrl()").
>
> I don't want to ever see that broken construct again. And I want to
> make sure that everybody is educated about how broken it was. I'm
> extremely unhappy that it came up again.
Well, if it makes you feel better, that was control dependencies and this
was data dependencies. So it was not -exactly- the same. ;-)
(Sorry, couldn't resist...)
> If it turns out that some architecture does actually need a barrier
> between a read and a dependent write, then that will mean that
>
> (a) we'll have to make up a _new_ barrier, because
> "smp_read_barrier_depends()" is not that barrier. We'll presumably
> then have to make that new barrier part of "rcu_derefence()" and
> friends.
Agreed. We can worry about whether or not we replace the current
smp_read_barrier_depends() with that new barrier when and if such
hardware appears.
> (b) we will have found an architecture with even worse memory
> ordering semantics than alpha, and we'll have to stop castigating
> alpha for being the worst memory ordering ever.
;-) ;-) ;-)
> but I sincerely hope that we'll never find that kind of broken architecture.
Apparently at least some hardware vendors are reading memory-barriers.txt,
so perhaps the odds of that kind of breakage have reduced.
Thanx, Paul
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | linux.kernel
csiph-web