Messages in this thread | | | Date | Mon, 11 May 2020 11:07:33 -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 06:34:13PM +0100, Will Deacon wrote: > 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?
Good point, and I would certainly hope so!
Thanx, Paul
| |