search for: lockless_dereference

...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. */ \ > > > (_________...

...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. */ \ > > > (_________...

...t to write code like this): struct foo { struct foo **a; }; struct foo b; struct foo c; struct foo d; struct foo e; struct foo f = { &d }; struct foo g = { &e }; struct foo *x = &b; void cpu0(void) { WRITE_ONCE(x, &f); } void cpu1(void) { struct foo *p; p = lockless_dereference(x); WRITE_ONCE(p->a, &x); } void cpu2(void) { r1 = lockless_dereference(f.a); WRITE_ONCE(*r1, &c); } It is legal to end the run with x==&f and r1==&x. To prevent this outcome, we do the following: struct foo { struct foo **a; }; struct foo b; struct foo c; st...

...()" 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 pro...

...()" 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 pro...

...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(); /*...

...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(); /*...

...t 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? WRC+addr+a...

...t 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? WRC+addr+a...

On 01/14/2016 04:14 AM, Will Deacon wrote: > On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > >> Moreover, there are voices against guarantee that it will be in future >> and that voices point me to Documentation/memory-barriers.txt section "DATA >> DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading >> address/index

On 01/14/2016 04:14 AM, Will Deacon wrote: > On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > >> Moreover, there are voices against guarantee that it will be in future >> and that voices point me to Documentation/memory-barriers.txt section "DATA >> DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading >> address/index

I need some time to understand your test examples. However, 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

I need some time to understand your test examples. However, 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

...= { &b }; > > struct foo x = { &c }; > > struct foo y = { &d }; > > struct foo *r1, *r2, *r3; > > > > void cpu0(void) > > { > > WRITE_ONCE(x.next, &y); > > } > > > > void cpu1(void) > > { > > r1 = lockless_dereference(x.next); > > WRITE_ONCE(r1->next, &x); > > } > > > > void cpu2(void) > > { > > r2 = lockless_dereference(y.next); > > r3 = READ_ONCE(r2->next); > > } > > > > In this case, it is legal to end the run with: > > &...

...= { &b }; > > struct foo x = { &c }; > > struct foo y = { &d }; > > struct foo *r1, *r2, *r3; > > > > void cpu0(void) > > { > > WRITE_ONCE(x.next, &y); > > } > > > > void cpu1(void) > > { > > r1 = lockless_dereference(x.next); > > WRITE_ONCE(r1->next, &x); > > } > > > > void cpu2(void) > > { > > r2 = lockless_dereference(y.next); > > r3 = READ_ONCE(r2->next); > > } > > > > In this case, it is legal to end the run with: > > &...

...d 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 > > somethin...

...rier > >>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); \ > >}) > > > &...

...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....

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra <peterz at 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

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra <peterz at 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