Messages in this thread | | | Date | Mon, 11 May 2020 18:34:13 +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 10:29:18AM -0700, Paul E. McKenney wrote: > 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.
No, I mean here is the code after this patch is applied:
for (;;) { if (data_race(prev->next) == node && cmpxchg(&prev->next, node, NULL) == node) break;
/* * We can only fail the cmpxchg() racing against an unlock(), * in which case we should observe @node->locked becomming * true. */ if (smp_load_acquire(&node->locked)) return true;
cpu_relax();
/* * Or we race against a concurrent unqueue()'s step-B, in which * case its step-C will write us a new @node->prev pointer. */ prev = READ_ONCE(node->prev); }
I'm saying that this READ_ONCE at the end of the loop should be sufficient to stop the compiler making value assumptions about prev->next. Do you agree?
Will
| |