search for: read_barrier_depend

Hi all, In an attempt to remove the remaining traces of [smp_]read_barrier_depends() following my previous patches to strengthen READ_ONCE() for Alpha [1], I ended up trying to decipher the read_barrier_depends() usage in the vhost driver: --->8 // drivers/vhost/vhost.c static int get_indirect(struct vhost_virtqueue *vq, struct iovec iov[], unsigned int iov_size, unsi...

Hi all, In an attempt to remove the remaining traces of [smp_]read_barrier_depends() following my previous patches to strengthen READ_ONCE() for Alpha [1], I ended up trying to decipher the read_barrier_depends() usage in the vhost driver: --->8 // drivers/vhost/vhost.c static int get_indirect(struct vhost_virtqueue *vq, struct iovec iov[], unsigned int iov_size, unsi...

Because READ_ONCE() now implies read_barrier_depends(), the read_barrier_depends() in next_desc() is now redundant. This commit therefore removes it and the related comments. Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com&g...

Because READ_ONCE() now implies read_barrier_depends(), the read_barrier_depends() in next_desc() is now redundant. This commit therefore removes it and the related comments. Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com&g...

.../3a5db0b108e0a40f08c2bcff6a675dbf632b91e0 Author: Paul E. McKenney <paulmck at linux.vnet.ibm.com> AuthorDate: Mon, 27 Nov 2017 09:45:10 -0800 Committer: Paul E. McKenney <paulmck at linux.vnet.ibm.com> CommitDate: Tue, 5 Dec 2017 11:57:55 -0800 drivers/vhost: Remove now-redundant read_barrier_depends() Because READ_ONCE() now implies read_barrier_depends(), the read_barrier_depends() in next_desc() is now redundant. This commit therefore removes it and the related comments. Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> Cc: "Michael S. Tsirkin" <mst at re...

On 2019/10/17 ??7:33, Will Deacon wrote: > Hi all, > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > ended up trying to decipher the read_barrier_depends() usage in the vhost > driver: > > --->8 > > // drivers/vhost/vhost.c > static int get_indirect(struct vhost_virtqueue *vq, > struct...

[Bah: I typoed the LKML address, so I've fixed it for this one] On Thu, Oct 17, 2019 at 12:33:40AM +0100, Will Deacon wrote: > Hi all, > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > ended up trying to decipher the read_barrier_depends() usage in the vhost > driver: > > --->8 > > // drivers/vhost/vhost.c > static int get_indirect(struct vhost_virtqueue *vq, > struc...

...st_log *log, unsigned int *log_num, >> struct vring_desc *indirect) >> { >> [...] >> >> /* We will use the result as an address to read from, so most >> * architectures only need a compiler barrier here. */ >> read_barrier_depends(); >> >> --->8 >> >> Unfortunately, although the barrier is commented (hurrah!), it's not >> particularly enlightening about the accesses making up the dependency >> chain, and I don't understand the supposed need for a compiler barrier >> eit...

On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: > On 2019/10/17 ??7:33, Will Deacon wrote: > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > > ended up trying to decipher the read_barrier_depends() usage in the vhost > > driver: > > > > --->8 > > > > // drivers/vhost/vhost.c > > static int get_indirect(s...

On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: > On 2019/10/17 ??7:33, Will Deacon wrote: > > In an attempt to remove the remaining traces of [smp_]read_barrier_depends() > > following my previous patches to strengthen READ_ONCE() for Alpha [1], I > > ended up trying to decipher the read_barrier_depends() usage in the vhost > > driver: > > > > --->8 > > > > // drivers/vhost/vhost.c > > static int get_indirect(s...

On 2019/10/19 ??4:58, Will Deacon wrote: > On Thu, Oct 17, 2019 at 10:17:18AM +0800, Jason Wang wrote: >> On 2019/10/17 ??7:33, Will Deacon wrote: >>> In an attempt to remove the remaining traces of [smp_]read_barrier_depends() >>> following my previous patches to strengthen READ_ONCE() for Alpha [1], I >>> ended up trying to decipher the read_barrier_depends() usage in the vhost >>> driver: >>> >>> --->8 >>> >>> // drivers/vhost/vhost.c >>> sta...

On Fri, Dec 01, 2017 at 11:51:16AM -0800, Paul E. McKenney wrote: > Because READ_ONCE() now implies read_barrier_depends(), the > read_barrier_depends() in next_desc() is now redundant. This commit > therefore removes it and the related comments. > > Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> > Cc: "Michael S. Tsirkin" <mst at redhat.com> > Cc: Jason Wan...

Since commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), there is no need to use smp_read_barrier_depends() outside of the Alpha architecture code. Unfortunately, there is precisely _one_ user in the vhost code, and there isn't an obvious READ_ONCE() access making the barrier redundant. However, on closer inspection (thanks...

On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > On s390 read_barrier_depends, smp_read_barrier_depends > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > > This is in preparation to refactoring this code area. > > Signed-o...

On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > On s390 read_barrier_depends, smp_read_barrier_depends > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > > This is in preparation to refactoring this code area. > > Signed-o...

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let...

...tch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~ /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/) { > + > + my $barriers = qr{ > + mb| > + rmb| > + wmb| > + read_barrier_depends > + }x; > + my $smp_barriers = qr{ > + store_release| > + load_acquire| > + store_mb| > + ($barriers) > +...

...tch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~ /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/) { > + > + my $barriers = qr{ > + mb| > + rmb| > + wmb| > + read_barrier_depends > + }x; > + my $smp_barriers = qr{ > + store_release| > + load_acquire| > + store_mb| > + ($barriers) > +...

On Tue, Dec 05, 2017 at 07:39:46PM +0100, Peter Zijlstra wrote: > On Tue, Dec 05, 2017 at 08:31:20PM +0200, Michael S. Tsirkin wrote: > > > Apropos, READ_ONCE is now asymmetrical with WRITE_ONCE. > > > > I can read a pointer with READ_ONCE and be sure the value > > is sane, but only if I also remember to put in smp_wmb before > > WRITE_ONCE. Otherwise the

On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > I don't see WRITE_ONCE inserting any barriers, release or > > write. > > Correct, never claimed there was. > > Just saying that: > > obj = READ_ONCE(*foo); > val = READ_ONCE(obj->val); > > Never needs