diff options
| author | Ingo Molnar <mingo@kernel.org> | 2024-01-08 09:31:16 +0100 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2024-01-08 09:55:31 +0100 |
| commit | 2b9d9e0a9ba0e24cb9c78336481f0ed8b2bc1ff2 (patch) | |
| tree | 19efa195a910151f5ba67a730e9534c700a9ad5c /Documentation/locking | |
| parent | 67a1723344cfe05430977483d6d3c7a999480143 (diff) | |
| download | lwn-2b9d9e0a9ba0e24cb9c78336481f0ed8b2bc1ff2.tar.gz lwn-2b9d9e0a9ba0e24cb9c78336481f0ed8b2bc1ff2.zip | |
locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked
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
Diffstat (limited to 'Documentation/locking')
| -rw-r--r-- | Documentation/locking/mutex-design.rst | 24 |
1 files changed, 18 insertions, 6 deletions
diff --git a/Documentation/locking/mutex-design.rst b/Documentation/locking/mutex-design.rst index 7572339b2f12..7c30b4aa5e28 100644 --- a/Documentation/locking/mutex-design.rst +++ b/Documentation/locking/mutex-design.rst @@ -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 ---------- |