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.
Attachment:
pgpLirzQ7ef0D.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
