Re: [patch 05/15] Generic Mutex Subsystem, mutex-core.patch

[Oleg Nesterov <oleg@tv-sign.ru>]

Ingo Molnar wrote:
> 
> * Oleg Nesterov <oleg@tv-sign.ru> wrote:
> 
> > > +   spin_lock(&lock->wait_lock);
> > > +   __add_waiter(lock, waiter, ti, task __IP__);
> > > +   set_task_state(task, task_state);
> >
> > I can't understand why __mutex_lock_common() does xchg() after adding
> > the waiter to the ->wait_list. We are holding ->wait_lock, we can't
> > race with __mutex_unlock_nonatomic() - it calls wake_up() and sets
> > ->count under this spinlock.
> 
> we must make sure that the drop has not been dropped meanwhile, on the
> way in, between the fastpath-unlock atomic op, and the xchg() here.

Sorry for noise, probably I should just re-read your explanation
tomorrow after some sleeping...

But why we can't add the waiter to ->wait_list _after_ xchg() ?
What makes the difference? Fastpath atomic op can happen before
or after xchg(), this is ok. Unlock path will look at ->wait_list
only after taking spinlock, at this time we already added this
waiter to the ->wait_list.

In other words: we are holding ->wait_lock, nobody can even look
at ->wait_list. We can add the waiter to ->wait_list before or
after atomic_xchg() - it does not matter.

Again no?

Oleg.