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: <5504BF8B.1090207@gmail.com>
Date:	Sun, 15 Mar 2015 01:08:59 +0200
From:	Matthias Bonne <lemonlime51@...il.com>
To:	Valdis.Kletnieks@...edu
CC:	Yann Droneaud <ydroneaud@...eya.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 03/10/15 16:59, Valdis.Kletnieks@...edu 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/