Re: Question on mutex code

[Matthias Bonne]

On 03/10/15 16:59, Valdis.Kletnieks@xxxxxx wrote:
> On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said:
>
> > > Consider the following sequence of events:
> > >
> > > 0. Suppose a mutex is locked by task A and has no waiters.
> > >
> > > 1. Task B calls mutex_trylock().
> > >
> > > 2. mutex_trylock() calls the architecture-specific
> > >      __mutex_fastpath_trylock(), with __mutex_trylock_slowpath() as
> > >      fail_fn.
> > >
> > > 3. According to the description of __mutex_fastpath_trylock() (for
> > >      example in include/asm-generic/mutex-dec.h), "if the architecture
> > >      has no effective trylock variant, it should call the fail_fn
> > >      spinlock-based trylock variant unconditionally". So
> > >      __mutex_fastpath_trylock() may now call __mutex_trylock_slowpath().
> > >
> > > 4. Task A releases the mutex.
> > >
> > > 5. Task B, in __mutex_trylock_slowpath, executes:
> > >
> > >           /* No need to trylock if the mutex is locked. */
> > >           if (mutex_is_locked(lock))
> > >                   return 0;
> > >
> > >      Since the mutex is no longer locked, the function continues.
> > >
> > > 6. Task C, which runs on a different cpu than task B, locks the mutex
> > >      again.
> > >
> > > 7. Task B, in __mutex_trylock_slowpath(), continues:
> > >
> > >           spin_lock_mutex(&lock->wait_lock, flags);
>
> B will spin here until C releases the lock.
>
> When that spin exits, C no longer holds the lock.  Re-do the analysis
> from this point.

Thank you for the review.

I don't think B waits for C here - C holds the mutex (lock), not the 
internal spinlock (lock->wait_lock). I might be wrong though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/