* 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?
Instead of duplicating unit tests, the right solution would be to generalize the locking self-tests and use them both during bootup and in kunit.
Thanks,
Ingo