Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-10 06:01:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked

Browse Source 
Clarify the mutex lock lifetime rules a bit more.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jann Horn <jannh@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20231201121808.GL3818@noisy.programming.kicks-ass.net
This commit is contained in:
Ingo Molnar 2024-01-08 09:31:16 +01:00
parent 67a1723344
commit 2b9d9e0a9b
1 changed files with 18 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Documentation/locking/mutex-design.rst
View File

@ -101,12 +101,24 @@ features that make lock debugging easier and faster:
- Detects multi-task circular deadlocks and prints out all affected
locks and tasks (and only those tasks).
Releasing a mutex is not an atomic operation: Once a mutex release operation
has begun, another context may be able to acquire the mutex before the release
operation has fully completed. The mutex user must ensure that the mutex is not
destroyed while a release operation is still in progress - in other words,
callers of mutex_unlock() must ensure that the mutex stays alive until
mutex_unlock() has returned.
Mutexes - and most other sleeping locks like rwsems - do not provide an
implicit reference for the memory they occupy, which reference is released
with mutex_unlock().
[ This is in contrast with spin_unlock() [or completion_done()], which
APIs can be used to guarantee that the memory is not touched by the
lock implementation after spin_unlock()/completion_done() releases
the lock. ]
mutex_unlock() may access the mutex structure even after it has internally
released the lock already - so it's not safe for another context to
acquire the mutex and assume that the mutex_unlock() context is not using
the structure anymore.
The mutex user must ensure that the mutex is not destroyed while a
release operation is still in progress - in other words, callers of
mutex_unlock() must ensure that the mutex stays alive until mutex_unlock()
has returned.
Interfaces
----------