[Question] race between spin_lock and spin_unlock

[Will Deacon]

On Tue, Jun 25, 2013 at 11:54:23AM +0100, Ming Lei wrote:
> On Tue, Jun 25, 2013 at 4:48 PM, Will Deacon <will.deacon at arm.com> wrote:
> > On Tue, Jun 25, 2013 at 05:31:44AM +0100, Ming Lei wrote:
> >> On Tue, Jun 25, 2013 at 12:37 AM, Will Deacon <will.deacon at arm.com> wrote:
> >> > You mean, if you had two CPUs spinning on a lock held by a third CPU? In
> >> > this case, the third CPU would have to release the lock, then one of the
> >> > waiters would have to acquire it, complete its critical section and finally
> >> > release it before the other waiter had executed its wfe (about three
> >> > instructions)...
> >>
> >> I mean the below situation:
> >>
> >> CPU0                                                                          CPU1
> >>
> >> spin_lock(&A)
> >>       StoreExcl(lock->next)
> >>                                                                                       spin_unlock(&A)
> >>                                                                                               Store(&lock->owner)
> >>                                                                                               dsb_sev()
> >>       interrupt comes
> >>               - wfe() called in the
> >>               irq handler
> >
> > Is this just a vanilla wfe, or as part of a spin_lock? If it's part of a
> > spin_lock, then we'll do a sev when we unlock it. An opencoded wfe in an
> 
> Suppose it is part of spin_lock(&B), and the sev in spin_unlock(&B) may happen
> in CPU2 or CPU3, then two sev() will come in CPU0.
> 
> My question is that if the wfe in spin_lock(&B) called from irq
> handler may clear
> the two sev().

Yes, as I said before, the events don't accumulate.

> If yes, the wfe() in spin_lock(&A) may still wait for later sev, right?  If not,
> it should be fine.

There's no problem, because spin_unlock(&B) in the interrupt handler on CPU0
(which must happen before it returns from the interrupt) will send a further
event and the wfe encountered when resuming spin_lock(&A) will not wait.

Will