user/sven/linux.git/Documentation/locking, branch v6.1.149

kcsan, seqlock: Support seqcount_latch_t

2024-12-14T18:53:19Z

[ Upstream commit 5c1806c41ce0a0110db5dd4c483cf2dc28b3ddf0 ] 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 Signed-off-by: Sasha Levin

hwspinlock: Introduce hwspin_lock_bust()

2024-09-08T05:53:09Z

[ Upstream commit 7c327d56597d8de1680cf24e956b704270d3d84a ] 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 Signed-off-by: Sasha Levin

Remove duplicate words inside documentation

2022-09-27T19:21:43Z

I have removed repeated `the` inside the documentation Signed-off-by: Akhil Raj Link: https://lore.kernel.org/r/20220827145359.32599-1-lf32.dev@gmail.com Signed-off-by: Jonathan Corbet

Documentation: Fix duplicate statement about raw_spinlock_t type

2022-03-25T19:30:08Z

Unless it was duplicate on purpose, to emphasize that a raw_spinlock_t is always a spinning lock regardless of PREEMPT_RT or kernel config, it's a bit odd that this text is duplicate. So, this patch just clean it up, keeping the consistency with the other sections of the text. Cc: Thomas Gleixner Fixes: 919e9e6395cf ("Documentation: Add lock ordering and nesting documentation") Signed-off-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20220321144133.49804-1-gpiccoli@igalia.com Signed-off-by: Jonathan Corbet

Documentation/locking/locktypes: Fix PREEMPT_RT _bh() description

2022-03-04T17:13:19Z

With PREEMPT_RT the _bh() version of a spinlock leaves preemption enabled, align the doc to say that instead of the opposite. Reported-by: Leah Leshchinsky Signed-off-by: Andrew Halaney Reviewed-by: Boqun Feng Link: https://lore.kernel.org/r/20220224212312.2601153-1-ahalaney@redhat.com Signed-off-by: Jonathan Corbet

Documentation/locking/locktypes: Update migrate_disable() bits.

2021-11-30T14:40:31Z

The initial implementation of migrate_disable() for mainline was a wrapper around preempt_disable(). RT kernels substituted this with a real migrate disable implementation. Later on mainline gained true migrate disable support, but the documentation was not updated. Update the documentation, remove the claims about migrate_disable() mapping to preempt_disable() on non-PREEMPT_RT kernels. Fixes: 74d862b682f51 ("sched: Make migrate_disable/enable() independent of RT") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211127163200.10466-2-bigeasy@linutronix.de

doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup

2021-10-01T17:01:05Z

The previous commits do exactly what this entry in the TODO file asks for, thus we can remove it now as it is no longer applicable. Signed-off-by: Fernando Ramos Reviewed-by: Sean Paul Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-18-greenfoo@u92.eu

Documentation: locking: fix references

2021-08-24T19:20:39Z

This patch fixes file references from txt to rst file ending in ww-mutex-design.rst and futex-requeue-pi.rst. While on it fix a spelling issue "desgin" to "design" reported by Matthew Wilcox. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20210823183143.1691344-1-aahringo@redhat.com Signed-off-by: Jonathan Corbet

locking/lockdep,doc: Improve readability of the block matrix

2021-05-31T08:14:54Z

The block condition matrix is using 'E' as the writer notation, however, the writer reminder below the matrix is using 'W', to make them consistent and make the matrix more readable, we'd better to use 'W' to represent writer. Suggested-by: Waiman Long Suggested-by: Boqun Feng Signed-off-by: Xiongwei Song Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Boqun Feng Link: https://lkml.kernel.org/r/1621868745-23311-1-git-send-email-sxwjean@me.com

Documentation: seqlock: s/LOCKTYPE/LOCKNAME/g

2020-12-09T16:08:49Z

Sequence counters with an associated write serialization lock are called seqcount_LOCKNAME_t. Fix the documentation accordingly. While at it, remove a paragraph that inappropriately discussed a seqlock.h implementation detail. Fixes: 6dd699b13d53 ("seqlock: seqcount_LOCKNAME_t: Standardize naming convention") Signed-off-by: Ahmed S. Darwish Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20201206162143.14387-2-a.darwish@linutronix.de