kernel/linux.git/Documentation/locking, branch v6.18.21

Documentation: locking: Add local_lock_nested_bh() to locktypes

2025-08-21T18:52:20+00:00

local_lock_nested_bh() is used within networking where applicable. Document why it is used and how it behaves. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20250815093858.930751-3-bigeasy@linutronix.de

Documentation: seqlock: Add a SPDX license identifier

2025-08-21T18:52:20+00:00

Add a SPDX identifier. The majority of the document has been written by Ahmed S. Darwish. Cc: Ahmed S. Darwish Acked-by: Ahmed S. Darwish Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20250815093858.930751-2-bigeasy@linutronix.de

hwspinlock: Remove unused hwspin_lock_get_id()

2025-03-21T22:12:04+00:00

hwspin_lock_get_id() has been unused since the original 2011 commit bd9a4c7df256 ("drivers: hwspinlock: add framework") Remove it and the corresponding docs. Note that the of_hwspin_lock_get_id() version is still in use, so leave that alone. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/20241215022023.181435-1-linux@treblig.org Signed-off-by: Bjorn Andersson

hwspinlock: Remove unused (devm_)hwspin_lock_request()

2025-03-21T22:12:04+00:00

devm_hwspin_lock_request() was added by 2018's commit 4f1acd758b08 ("hwspinlock: Add devm_xxx() APIs to request/free hwlock") however, it's never been used, everyone uses the devm_hwspin_lock_request_specific() call instead. Remove it. Similarly, the none-devm variant isn't used. Remove it, and the referring documentation. Signed-off-by: Dr. David Alan Gilbert Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/20241027205445.239108-1-linux@treblig.org Signed-off-by: Bjorn Andersson

locking/Documentation: Fix grammar in percpu-rw-semaphore.rst

2024-11-13T09:59:01+00:00

s/'is initialized'/'is initialized with' Signed-off-by: Xiu Jianfeng Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20241112025724.474881-1-xiujianfeng@huaweicloud.com

kcsan, seqlock: Support seqcount_latch_t

2024-11-05T11:55:35+00:00

While fuzzing an arm64 kernel, Alexander Potapenko reported: | BUG: KCSAN: data-race in ktime_get_mono_fast_ns / timekeeping_update | | write to 0xffffffc082e74248 of 56 bytes by interrupt on cpu 0: | update_fast_timekeeper kernel/time/timekeeping.c:430 [inline] | timekeeping_update+0x1d8/0x2d8 kernel/time/timekeeping.c:768 | timekeeping_advance+0x9e8/0xb78 kernel/time/timekeeping.c:2344 | update_wall_time+0x18/0x38 kernel/time/timekeeping.c:2360 | [...] | | read to 0xffffffc082e74258 of 8 bytes by task 5260 on cpu 1: | __ktime_get_fast_ns kernel/time/timekeeping.c:372 [inline] | ktime_get_mono_fast_ns+0x88/0x174 kernel/time/timekeeping.c:489 | init_srcu_struct_fields+0x40c/0x530 kernel/rcu/srcutree.c:263 | init_srcu_struct+0x14/0x20 kernel/rcu/srcutree.c:311 | [...] | | value changed: 0x000002f875d33266 -> 0x000002f877416866 | | Reported by Kernel Concurrency Sanitizer on: | CPU: 1 UID: 0 PID: 5260 Comm: syz.2.7483 Not tainted 6.12.0-rc3-dirty #78 This is a false positive data race between a seqcount latch writer and a reader accessing stale data. Since its introduction, KCSAN has never understood the seqcount_latch interface (due to being unannotated). Unlike the regular seqlock interface, the seqcount_latch interface for latch writers never has had a well-defined critical section, making it difficult to teach tooling where the critical section starts and ends. Introduce an instrumentable (non-raw) seqcount_latch interface, with which we can clearly denote writer critical sections. This both helps readability and tooling like KCSAN to understand when the writer is done updating all latch copies. Fixes: 88ecd153be95 ("seqlock, kcsan: Add annotations for KCSAN") Reported-by: Alexander Potapenko Co-developed-by: "Peter Zijlstra (Intel)" Signed-off-by: "Peter Zijlstra (Intel)" Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20241104161910.780003-4-elver@google.com

hwspinlock: Introduce hwspin_lock_bust()

2024-05-29T19:52:26+00:00

When a remoteproc crashes or goes down unexpectedly this can result in a state where locks held by the remoteproc will remain locked possibly resulting in deadlock. This new API hwspin_lock_bust() allows hwspinlock implementers to define a bust operation for freeing previously acquired hwspinlocks after verifying ownership of the acquired lock. Signed-off-by: Richard Maina Reviewed-by: Bjorn Andersson Signed-off-by: Chris Lew Link: https://lore.kernel.org/r/20240529-hwspinlock-bust-v3-1-c8b924ffa5a2@quicinc.com Signed-off-by: Bjorn Andersson

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

2024-01-08T08:55:31+00:00

Clarify the mutex lock lifetime rules a bit more. Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Jann Horn Cc: Linus Torvalds Link: https://lore.kernel.org/r/20231201121808.GL3818@noisy.programming.kicks-ass.net

locking/mutex: Document that mutex_unlock() is non-atomic

2023-12-01T10:27:43+00:00

I have seen several cases of attempts to use mutex_unlock() to release an object such that the object can then be freed by another task. This is not safe because mutex_unlock(), in the MUTEX_FLAG_WAITERS && !MUTEX_FLAG_HANDOFF case, accesses the mutex structure after having marked it as unlocked; so mutex_unlock() requires its caller to ensure that the mutex stays alive until mutex_unlock() returns. If MUTEX_FLAG_WAITERS is set and there are real waiters, those waiters have to keep the mutex alive, but we could have a spurious MUTEX_FLAG_WAITERS left if an interruptible/killable waiter bailed between the points where __mutex_unlock_slowpath() did the cmpxchg reading the flags and where it acquired the wait_lock. ( With spinlocks, that kind of code pattern is allowed and, from what I remember, used in several places in the kernel. ) Document this, such a semantic difference between mutexes and spinlocks is fairly unintuitive. [ mingo: Made the changelog a bit more assertive, refined the comments. ] Signed-off-by: Jann Horn Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20231130204817.2031407-1-jannh@google.com

Documentation: Fix typos

2023-08-18T17:29:03+00:00

Fix typos in Documentation. Signed-off-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20230814212822.193684-4-helgaas@kernel.org Signed-off-by: Jonathan Corbet