search for: write_once

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index ec7861457b84..b2a93e3fa67b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -387,6 +387,7 @@

...64/include/asm/barrier.h b/arch/ia64/include/asm/barrier.h > index df896a1..209c4b8 100644 > --- a/arch/ia64/include/asm/barrier.h > +++ b/arch/ia64/include/asm/barrier.h > @@ -77,7 +77,7 @@ do { \ > ___p1; \ > }) > > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > /* > * The group barrier in front of the rsm & ssm are necessary to ensure > diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/ba...

...64/include/asm/barrier.h b/arch/ia64/include/asm/barrier.h > index df896a1..209c4b8 100644 > --- a/arch/ia64/include/asm/barrier.h > +++ b/arch/ia64/include/asm/barrier.h > @@ -77,7 +77,7 @@ do { \ > ___p1; \ > }) > > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > /* > * The group barrier in front of the rsm & ssm are necessary to ensure > diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/ba...

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > WRITE_ONCE(obj->val, 1); > > > smp_wmb(); > > > WRITE_ONCE(*foo, obj); > > > > I believe Peter was instead suggesting: > > > > WRITE_ONCE(obj->val, 1); > > smp_store_release(foo, obj); > > Isn't that more expensive though? Depends on the arch...

On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > WRITE_ONCE(obj->val, 1); > > > smp_wmb(); > > > WRITE_ONCE(*foo, obj); > > > > I believe Peter was instead suggesting: > > > > WRITE_ONCE(obj->val, 1); > > smp_store_release(foo, obj); > > Isn't that more expensive though? Depends on the arch...

On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > 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 a barrier (except on Alpha an...

On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > 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 a barrier (except on Alpha an...

...e to easily find them. > > The advantage of introducing the SINGLE_{LOAD,STORE}() helpers is that > they compiletime validate this the size is 'right' and can runtime check > alignment constraints. > > IE, they are strictly stronger than {READ,WRITE}_ONCE(). Uh, so, READ/WRITE_ONCE are non-atomic now. I missed that. If READ/WRITE_ONCE are non-atomic, half of kernel is broken. All these loads of flags, ringbuffer positions, pointers, etc are broken. What about restoring READ/WRITE_ONCE as atomic, and introducing separate primitives for _non_ atomic loads/stores? It seems to...

...e to easily find them. > > The advantage of introducing the SINGLE_{LOAD,STORE}() helpers is that > they compiletime validate this the size is 'right' and can runtime check > alignment constraints. > > IE, they are strictly stronger than {READ,WRITE}_ONCE(). Uh, so, READ/WRITE_ONCE are non-atomic now. I missed that. If READ/WRITE_ONCE are non-atomic, half of kernel is broken. All these loads of flags, ringbuffer positions, pointers, etc are broken. What about restoring READ/WRITE_ONCE as atomic, and introducing separate primitives for _non_ atomic loads/stores? It seems to...

...t; > >>> 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> <----------- > >>>SYNC_RMB is here > >>> D = *Q; > >>... > >>>Anot...

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 a barrier (except on Alpha and we want to make that go away). Simply because a CPU needs to complete the load of @obj before it c...

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 a barrier (except on Alpha and we want to make that go away). Simply because a CPU needs to complete the load of @obj before it c...

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 pointer is ok but no guarantees > about the data pointed to. That was already the case on everything except Alpha. And the cano...

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 pointer is ok but no guarantees > about the data pointed to. That was already the case on everything except Alpha. And the cano...

...he data load: >>> >>> 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> <----------- >>> SYNC_RMB is here >>> D = *Q; >> ... >>> Another example of where dat...

...he data load: >>> >>> 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> <----------- >>> SYNC_RMB is here >>> D = *Q; >> ... >>> Another example of where dat...

...), 4 deletions(-) diff --git a/arch/ia64/include/asm/barrier.h b/arch/ia64/include/asm/barrier.h index df896a1..209c4b8 100644 --- a/arch/ia64/include/asm/barrier.h +++ b/arch/ia64/include/asm/barrier.h @@ -77,7 +77,7 @@ do { \ ___p1; \ }) -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) /* * The group barrier in front of the rsm & ssm are necessary to ensure diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h index 0eca6ef..a...

On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native

On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native

On Tue, Dec 05, 2017 at 10:28:38PM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 08:57:52PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 09:51:48PM +0200, Michael S. Tsirkin wrote: > > > > > WRITE_ONCE(obj->val, 1); > > > > > smp_wmb(); > > > > > WRITE_ONCE(*foo, obj); > > > > > > > > I believe Peter was instead suggesting: > > > > > > > > WRITE_ONCE(obj->val, 1); > > > > smp_store_release(foo, obj);...