Messages in this thread | | | Date | Mon, 11 May 2020 10:29:18 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH -next v2] locking/osq_lock: annotate a data race in osq_lock |
| |
On Mon, May 11, 2020 at 05:52:17PM +0100, Will Deacon wrote: > 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?
Yes, that would also work. Either have the cpu_relax() or a barrier() or whatever on the one hand, or, as you say, turn the data_race() into a READ_ONCE(). I personally prefer the READ_ONCE() myself, unless that would undesirably suppress other KCSAN warnings.
Thanx, Paul
| |