On Sat, Aug 15, 2020 at 4:17 AM Ingo Molnar mingo@kernel.org wrote:
- Peter Zijlstra peterz@infradead.org wrote:
On Sat, Aug 15, 2020 at 10:30:29AM +0200, Ingo Molnar wrote:
- Uriel Guajardo urielguajardojr@gmail.com wrote:
From: Uriel Guajardo urielguajardo@google.com
KUnit will fail tests upon observing a lockdep failure. Because lockdep turns itself off after its first failure, only fail the first test and warn users to not expect any future failures from lockdep.
Similar to lib/locking-selftest [1], we check if the status of debug_locks has changed after the execution of a test case. However, we do not reset lockdep afterwards.
Like the locking selftests, we also fix possible preemption count corruption from lock bugs.
--- a/lib/kunit/Makefile +++ b/lib/kunit/Makefile
+void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep *lockdep) {
- int saved_preempt_count = lockdep->preempt_count;
- bool saved_debug_locks = lockdep->debug_locks;
- if (DEBUG_LOCKS_WARN_ON(preempt_count() != saved_preempt_count))
preempt_count_set(saved_preempt_count);+#ifdef CONFIG_TRACE_IRQFLAGS
- if (softirq_count())
current->softirqs_enabled = 0;- else
current->softirqs_enabled = 1;+#endif
- if (saved_debug_locks && !debug_locks) {
kunit_set_failure(test);kunit_warn(test, "Dynamic analysis tool failure from LOCKDEP.");kunit_warn(test, "Further tests will have LOCKDEP disabled.");- }
So this basically duplicates what the boot-time locking self-tests do, in a poor fashion?
No, it makes sure that any kunit based self-test fails when it messes up it's locking.
We have a flag for whether lockdep is running though, so is this basically a very complicated way to parse /proc/lockdep_debug? :-)
I may be missing something here, but what would be the advantage of using another flag or using other means to find lockdep's status?
This patch is basically checking if debug_locks has changed after a KUnit test case has executed. It's not sufficient to only check if debug_locks is off, since it could have already been off many test cases ago.
I imagine the only difference would be replacing "debug_locks" with another flag or code checking lockdep's status, and I don't see that as being any less complicated.