linux-kernel - Re: Question on mutex code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <65060.1425999557@turing-police.cc.vt.edu>
Date:	Tue, 10 Mar 2015 10:59:17 -0400
From:	Valdis.Kletnieks@...edu
To:	Yann Droneaud <ydroneaud@...eya.com>
Cc:	Matthias Bonne <lemonlime51@...il.com>,
	kernelnewbies@...nelnewbies.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: Question on mutex code

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.

Content of type "application/pgp-signature" skipped