From: Uriel Guajardo <[email protected]>
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.
Depends on kunit: support failure from dynamic analysis tools [2]
[1] https://elixir.bootlin.com/linux/v5.7.12/source/lib/locking-selftest.c#L1137
[2] https://lore.kernel.org/linux-kselftest/[email protected]/
Signed-off-by: Uriel Guajardo <[email protected]>
---
v3 changes:
- Moved lockdep checking to own file [Alan]
- Fail if preemption count changes during test [Peter]
v2 changes:
- Removed lockdep_reset [Peter]
- Added warning to users about lockdep shutting off
---
include/kunit/kunit-lockdep.h | 38 +++++++++++++++++++++++++++++++++++
lib/kunit/Makefile | 2 ++
lib/kunit/kunit-lockdep.c | 37 ++++++++++++++++++++++++++++++++++
lib/kunit/test.c | 7 ++++++-
4 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/kunit-lockdep.h
create mode 100644 lib/kunit/kunit-lockdep.c
diff --git a/include/kunit/kunit-lockdep.h b/include/kunit/kunit-lockdep.h
new file mode 100644
index 000000000000..9cb8b931a9c6
--- /dev/null
+++ b/include/kunit/kunit-lockdep.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Lockdep integration into KUnit tests
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Uriel Guajardo <[email protected]>
+ */
+#ifndef _KUNIT_LOCKDEP_H
+#define _KUNIT_LOCKDEP_H
+
+#include <kunit/test.h>
+
+struct kunit_lockdep {
+ int preempt_count;
+ bool debug_locks;
+};
+
+#if IS_ENABLED(CONFIG_LOCKDEP)
+
+void kunit_init_lockdep(struct kunit *test, struct kunit_lockdep *lockdep);
+
+void kunit_check_lockdep(struct kunit *test, struct kunit_lockdep *lockdep);
+
+#else
+
+static inline void kunit_init_lockdep(struct kunit *test,
+ struct kunit_lockdep *lockdep)
+{
+}
+
+static inline void kunit_check_lockdep(struct kunit *test,
+ struct kunit_lockdep *lockdep)
+{
+}
+
+#endif
+
+#endif /* _KUNIT_LOCKDEP_H */
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index 724b94311ca3..084806cea994 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -5,6 +5,8 @@ kunit-objs += test.o \
assert.o \
try-catch.o
+obj-$(CONFIG_LOCKDEP) += kunit-lockdep.o
+
ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
kunit-objs += debugfs.o
endif
diff --git a/lib/kunit/kunit-lockdep.c b/lib/kunit/kunit-lockdep.c
new file mode 100644
index 000000000000..cc8c1baf25cd
--- /dev/null
+++ b/lib/kunit/kunit-lockdep.c
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Lockdep integration into KUnit tests
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Uriel Guajardo <[email protected]>
+ */
+
+#include <kunit/kunit-lockdep.h>
+#include <linux/debug_locks.h>
+#include <linux/sched.h>
+
+void kunit_init_lockdep(struct kunit *test, struct kunit_lockdep *lockdep) {
+ lockdep->debug_locks = debug_locks;
+ lockdep->preempt_count = preempt_count();
+}
+
+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.");
+ }
+}
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index d8189d827368..7f0af0465e6f 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -7,6 +7,7 @@
*/
#include <kunit/test.h>
+#include <kunit/kunit-lockdep.h>
#include <linux/kernel.h>
#include <linux/kref.h>
#include <linux/sched/debug.h>
@@ -290,6 +291,9 @@ static void kunit_try_run_case(void *data)
struct kunit_suite *suite = ctx->suite;
struct kunit_case *test_case = ctx->test_case;
+ struct kunit_lockdep lockdep;
+ kunit_init_lockdep(test, &lockdep);
+
current->kunit_test = test;
/*
@@ -298,7 +302,8 @@ static void kunit_try_run_case(void *data)
* thread will resume control and handle any necessary clean up.
*/
kunit_run_case_internal(test, suite, test_case);
- /* This line may never be reached. */
+ /* These lines may never be reached. */
+ kunit_check_lockdep(test, &lockdep);
kunit_run_case_cleanup(test, suite);
}
--
2.28.0.220.ged08abb693-goog
* Peter Zijlstra <[email protected]> wrote:
> On Sat, Aug 15, 2020 at 10:30:29AM +0200, Ingo Molnar wrote:
> >
> > * Uriel Guajardo <[email protected]> wrote:
> >
> > > From: Uriel Guajardo <[email protected]>
> > >
> > > 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? :-)
Thanks,
Ingo
On Sat, Aug 15, 2020 at 10:30:29AM +0200, Ingo Molnar wrote:
>
> * Uriel Guajardo <[email protected]> wrote:
>
> > From: Uriel Guajardo <[email protected]>
> >
> > 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.
* Uriel Guajardo <[email protected]> wrote:
> From: Uriel Guajardo <[email protected]>
>
> 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
On Sat, Aug 15, 2020 at 4:17 AM Ingo Molnar <[email protected]> wrote:
>
>
> * Peter Zijlstra <[email protected]> wrote:
>
> > On Sat, Aug 15, 2020 at 10:30:29AM +0200, Ingo Molnar wrote:
> > >
> > > * Uriel Guajardo <[email protected]> wrote:
> > >
> > > > From: Uriel Guajardo <[email protected]>
> > > >
> > > > 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.