kernel/linux.git/lib/locking-selftest.c, branch v6.6.132

lockdep/selftests: Use SBRM APIs for wait context tests

2023-07-26T10:29:13+00:00

The "__cleanup__" attribute is already used for wait context tests, so using it for locking tests has already been proven working. Now since SBRM APIs are merged, let's use these APIs instead of a local guard framework. This also helps testing SBRM APIs. Note that originally the tests don't rely on the cleanup ordering of two variables in the same scope, but since now it's something we'd like to assume and rely on[1], drop the extra scope in inner_in_outer() function. Again this gives us another opportunity to test the compiler behavior. [1]: https://lore.kernel.org/lkml/CAHk-=whEsr6fuVSdsoNPokLR2fZiGuo_hCLyrS-LCw7hT_N7cQ@mail.gmail.com/ Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20230715235257.110325-1-boqun.feng@gmail.com

lockdep/selftests: Adapt ww-tests for PREEMPT_RT

2021-12-04T09:56:24+00:00

The ww-mutex selftest operates directly on ww_mutex::base and assumes its type is struct mutex. This isn't true on PREEMPT_RT which turns the mutex into a rtmutex. Add a ww_mutex_base_ abstraction which maps to the relevant mutex_ or rt_mutex_ function. Change the CONFIG_DEBUG_MUTEXES ifdef to DEBUG_WW_MUTEXES. The latter is true for the MUTEX and RTMUTEX implementation of WW-MUTEX. The assignment is required in order to pass the tests. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20211129174654.668506-10-bigeasy@linutronix.de

lockdep/selftests: Skip the softirq related tests on PREEMPT_RT

2021-12-04T09:56:24+00:00

The softirq context on PREEMPT_RT is different compared to !PREEMPT_RT. As such lockdep_softirq_enter() is a nop and the all the "softirq safe" tests fail on PREEMPT_RT because there is no difference. Skip the softirq context tests on PREEMPT_RT. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20211129174654.668506-9-bigeasy@linutronix.de

lockdep/selftests: Unbalanced migrate_disable() & rcu_read_lock().

2021-12-04T09:56:24+00:00

The tests with unbalanced lock() + unlock() operation leave a modified preemption counter behind which is then reset to its original value after the test. The spin_lock() function on PREEMPT_RT does not include a preempt_disable() statement but migrate_disable() and read_rcu_lock(). As a consequence both counter never get back to their original value and the system explodes later after the selftest. In the double-unlock case on PREEMPT_RT, the migrate_disable() and RCU code will trigger a warning which should be avoided. These counter should not be decremented below their initial value. Save both counters and bring them back to their original value after the test. In the double-unlock case, increment both counter in advance to they become balanced after the double unlock. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20211129174654.668506-8-bigeasy@linutronix.de

lockdep/selftests: Avoid using local_lock_{acquire|release}().

2021-12-04T09:56:24+00:00

The local_lock related functions local_lock_acquire() local_lock_release() are part of the internal implementation and should be avoided. Define the lock as DEFINE_PER_CPU so the normal local_lock() function can be used. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20211129174654.668506-7-bigeasy@linutronix.de

kernel/locking: Add context to ww_mutex_trylock()

2021-09-17T13:08:41+00:00

i915 will soon gain an eviction path that trylock a whole lot of locks for eviction, getting dmesg failures like below: BUG: MAX_LOCK_DEPTH too low! turning off the locking correctness validator. depth: 48 max: 48! 48 locks held by i915_selftest/5776: #0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160 #1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915] #2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915] #3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915] #4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] ... #46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] #47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915] INFO: lockdep is turned off. Fixing eviction to nest into ww_class_acquire is a high priority, but it requires a rework of the entire driver, which can only be done one step at a time. As an intermediate solution, add an acquire context to ww_mutex_trylock, which allows us to do proper nesting annotations on the trylocks, making the above lockdep splat disappear. This is also useful in regulator_lock_nested, which may avoid dropping regulator_nesting_mutex in the uncontended path, so use it there. TTM may be another user for this, where we could lock a buffer in a fastpath with list locks held, without dropping all locks we hold. [peterz: rework actual ww_mutex_trylock() implementations] Signed-off-by: Maarten Lankhorst Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net

lockdep/selftest: Remove wait-type RCU_CALLBACK tests

2021-06-22T14:42:08+00:00

The problem is that rcu_callback_map doesn't have wait_types defined, and doing so would make it indistinguishable from SOFTIRQ in any case. Remove it. Fixes: 9271a40d2a14 ("lockdep/selftest: Add wait context selftests") Signed-off-by: Peter Zijlstra (Intel) Tested-by: Joerg Roedel Link: https://lore.kernel.org/r/20210617190313.384290291@infradead.org

lockdep/selftests: Fix selftests vs PROVE_RAW_LOCK_NESTING

2021-06-22T14:42:08+00:00

When PROVE_RAW_LOCK_NESTING=y many of the selftests FAILED because HARDIRQ context is out-of-bounds for spinlocks. Instead make the default hardware context the threaded hardirq context, which preserves the old locking rules. The wait-type specific locking selftests will have a non-threaded HARDIRQ variant. Fixes: de8f5e4f2dc1 ("lockdep: Introduce wait-type checks") Signed-off-by: Peter Zijlstra (Intel) Tested-by: Joerg Roedel Link: https://lore.kernel.org/r/20210617190313.322096283@infradead.org

locking/selftests: Add a selftest for check_irq_usage()

2021-06-22T14:42:07+00:00

Johannes Berg reported a lockdep problem which could be reproduced by the special test case introduced in this patch, so add it. Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210618170110.3699115-5-boqun.feng@gmail.com

locking/selftests: Add local_lock inversion tests

2021-01-14T10:20:18+00:00

Test the local_lock_t inversion scenarios. Signed-off-by: Peter Zijlstra (Intel)