On 03/10/15 16:59, Valdis.Kletnieks at vt.edu wrote:

On Tue, 10 Mar 2015 14:03:59 +0100, Yann Droneaud said:

quoted

quoted

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.