Messages in this thread | | | Date | Mon, 11 May 2020 17:52:17 +0100 | From | Will Deacon <> | Subject | Re: [PATCH -next v2] locking/osq_lock: annotate a data race in osq_lock |
| |
On Mon, May 11, 2020 at 09:43:19AM -0700, Paul E. McKenney wrote: > On Mon, May 11, 2020 at 04:58:13PM +0100, Will Deacon wrote: > > On Sat, May 09, 2020 at 02:36:54PM -0700, Paul E. McKenney wrote: > > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c > > > index 1f77349..1de006e 100644 > > > --- a/kernel/locking/osq_lock.c > > > +++ b/kernel/locking/osq_lock.c > > > @@ -154,7 +154,11 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > > */ > > > > > > for (;;) { > > > - if (prev->next == node && > > > + /* > > > + * cpu_relax() below implies a compiler barrier which would > > > + * prevent this comparison being optimized away. > > > + */ > > > + if (data_race(prev->next) == node && > > > cmpxchg(&prev->next, node, NULL) == node) > > > break; > > > > I'm fine with the data_race() placement, but I don't find the comment > > very helpful. We assign the result of a READ_ONCE() to 'prev' in the > > loop, so I don't think that the cpu_relax() is really relevant. > > Suppose that the compiler loaded a value that was not equal to "node". > In that case, the cmpxchg() won't happen, so something else must force > the compiler to do the reload in order to avoid an infinite loop, right? > Or am I missing something here?
Then we just go round the loop and reload prev:
prev = READ_ONCE(node->prev);
which should be enough to stop the compiler, no?
Will
| |