search for: read_once

...fdef CONFIG_HYPERV_TSCPAGE > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&hvclock_page; > + u64 sequence, scale, offset, current_tick, cur_tsc; > + > + while (1) { > + sequence = READ_ONCE(tsc_pg->tsc_sequence); > + if (!sequence) > + break; > + > + scale = READ_ONCE(tsc_pg->tsc_scale); > + offset = READ_ONCE(tsc_pg->tsc_offset); > + rdtscll(cur_tsc); > + > + current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset; > + > + if (READ_O...

...fdef CONFIG_HYPERV_TSCPAGE > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&hvclock_page; > + u64 sequence, scale, offset, current_tick, cur_tsc; > + > + while (1) { > + sequence = READ_ONCE(tsc_pg->tsc_sequence); > + if (!sequence) > + break; > + > + scale = READ_ONCE(tsc_pg->tsc_scale); > + offset = READ_ONCE(tsc_pg->tsc_offset); > + rdtscll(cur_tsc); > + > + current_tick = mul_u64_u64_shr(cur_tsc, scale, 64) + offset; > + > + if (READ_O...

...> On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: [ . . . ] > > > and this barrier is no longer paired with anything until > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > Barrier pairing was a useful tool to check code validity, > > > maybe there are other, better tools now. > > > > There are quite a few people who say that smp_store_release() is > > easier for the tools to analyze than is smp_wmb(). My ex...

...> On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: [ . . . ] > > > and this barrier is no longer paired with anything until > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > Barrier pairing was a useful tool to check code validity, > > > maybe there are other, better tools now. > > > > There are quite a few people who say that smp_store_release() is > > easier for the tools to analyze than is smp_wmb(). My ex...

On 15/02/15 17:30, Raghavendra K T wrote: > --- a/arch/x86/xen/spinlock.c > +++ b/arch/x86/xen/spinlock.c > @@ -41,7 +41,7 @@ static u8 zero_stats; > static inline void check_zero(void) > { > u8 ret; > - u8 old = ACCESS_ONCE(zero_stats); > + u8 old = READ_ONCE(zero_stats); > if (unlikely(old)) { > ret = cmpxchg(&zero_stats, old, 0); > /* This ensures only one fellow resets the stat */ > @@ -112,6 +112,7 @@ __visible void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) > struct xen_lock_waiting *w = this_cpu_ptr...

On 15/02/15 17:30, Raghavendra K T wrote: > --- a/arch/x86/xen/spinlock.c > +++ b/arch/x86/xen/spinlock.c > @@ -41,7 +41,7 @@ static u8 zero_stats; > static inline void check_zero(void) > { > u8 ret; > - u8 old = ACCESS_ONCE(zero_stats); > + u8 old = READ_ONCE(zero_stats); > if (unlikely(old)) { > ret = cmpxchg(&zero_stats, old, 0); > /* This ensures only one fellow resets the stat */ > @@ -112,6 +112,7 @@ __visible void xen_lock_spinning(struct arch_spinlock *lock, __ticket_t want) > struct xen_lock_waiting *w = this_cpu_ptr...

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, unsigned int *out_num, unsigned int *in_num, struct vhost_...

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, unsigned int *out_num, unsigned int *in_num, struct vhost_...

...t; * Greg KH <gregkh at linuxfoundation.org> wrote: > >>>> It's: >>>> >>>> d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock >>> >>> Yes, This is the original patch. Please note I have taken out the >>> READ_ONCE changes from the original patch to avoid build warnings >>> mentioned below. >>> (Those READ_ONCE changes were cosmetic and was not present in the >>> previous versions) >>> >>>> >>>> You'll also need this fix from Linus to avoid (harm...

...t; * Greg KH <gregkh at linuxfoundation.org> wrote: > >>>> It's: >>>> >>>> d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock >>> >>> Yes, This is the original patch. Please note I have taken out the >>> READ_ONCE changes from the original patch to avoid build warnings >>> mentioned below. >>> (Those READ_ONCE changes were cosmetic and was not present in the >>> previous versions) >>> >>>> >>>> You'll also need this fix from Linus to avoid (harm...

...ney wrote: > > > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > > > > [ . . . ] > > > > > > > and this barrier is no longer paired with anything until > > > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > > > > > Barrier pairing was a useful tool to check code validity, > > > > > maybe there are other, better tools now. > > > > > > > > There are quite a few people who say that smp_store_release() is > > > &g...

...ney wrote: > > > > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > > > > [ . . . ] > > > > > > > and this barrier is no longer paired with anything until > > > > > you realize there's a dependency barrier within READ_ONCE. > > > > > > > > > > Barrier pairing was a useful tool to check code validity, > > > > > maybe there are other, better tools now. > > > > > > > > There are quite a few people who say that smp_store_release() is > > > &g...

...ed into, 1. move slowpath flag 2. fix memory corruption in completion problem ?? Changes since V4: - one more usage of tickets_equal() (Oleg) - head > tail situation can lead to false contended check (Oleg) Changes since V3: - Detailed changelog (PeterZ) - Replace ACCESS_ONCE with READ_ONCE (oleg) - Add xen changes (Oleg) - Correct break logic in unlock_wait() (Oleg) Changes since V2: - Move the slowpath flag to head, this enables xadd usage in unlock code and inturn we can get rid of read/write after unlock (Oleg) - usage of ticket_equals (Oleg) Changes since V1: - A...

...ed into, 1. move slowpath flag 2. fix memory corruption in completion problem ?? Changes since V4: - one more usage of tickets_equal() (Oleg) - head > tail situation can lead to false contended check (Oleg) Changes since V3: - Detailed changelog (PeterZ) - Replace ACCESS_ONCE with READ_ONCE (oleg) - Add xen changes (Oleg) - Correct break logic in unlock_wait() (Oleg) Changes since V2: - Move the slowpath flag to head, this enables xadd usage in unlock code and inturn we can get rid of read/write after unlock (Oleg) - usage of ticket_equals (Oleg) Changes since V1: - A...

...>>> arch/x86/kernel/kvm.c | 7 ++- > >>> arch/x86/xen/spinlock.c | 7 ++- > >>> 3 files changed, 58 insertions(+), 50 deletions(-) > >>> > >>>Changes for stable: > >>> - Don't replace the ACCESS_ONCE to READ_ONCE which would cause horraneous > >>> Compiler warnings (Linus, David Vbriel, PeterZ, Ingo) > >> > >>What is the git commit id of this in Linus's tree? What > >>stable tree(s) do you want this applied to? > > > >It's: > > > >...

...>>> arch/x86/kernel/kvm.c | 7 ++- > >>> arch/x86/xen/spinlock.c | 7 ++- > >>> 3 files changed, 58 insertions(+), 50 deletions(-) > >>> > >>>Changes for stable: > >>> - Don't replace the ACCESS_ONCE to READ_ONCE which would cause horraneous > >>> Compiler warnings (Linus, David Vbriel, PeterZ, Ingo) > >> > >>What is the git commit id of this in Linus's tree? What > >>stable tree(s) do you want this applied to? > > > >It's: > > > >...

On 2016?11?24? 18:25, Mark Rutland wrote: > The virtio tools implementation of READ_ONCE() has a single parameter called > 'var', but erroneously refers to 'val' for its cast, and thus won't work unless > there's a variable of the correct type that happens to be called 'var'. > > Fix this with s/var/val/, making READ_ONCE() work as expected r...

4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Rutland <mark.rutland at arm.com> commit 5da889c795b1fbefc9d8f058b54717ab8ab17891 upstream. The virtio tools implementation of READ_ONCE() has a single parameter called 'var', but erroneously refers to 'val' for its cast, and thus won't work unless there's a variable of the correct type that happens to be called 'var'. Fix this with s/var/val/, making READ_ONCE() work as expected regardless. Fixes:...

The virtio tools implementation of READ_ONCE() has a single parameter called 'var', but erroneously refers to 'val' for its cast, and thus won't work unless there's a variable of the correct type that happens to be called 'var'. Fix this with s/var/val/, making READ_ONCE() work as expected regardless. Fixes:...

4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mark Rutland <mark.rutland at arm.com> commit 5da889c795b1fbefc9d8f058b54717ab8ab17891 upstream. The virtio tools implementation of READ_ONCE() has a single parameter called 'var', but erroneously refers to 'val' for its cast, and thus won't work unless there's a variable of the correct type that happens to be called 'var'. Fix this with s/var/val/, making READ_ONCE() work as expected regardless. Fixes:...