Locking selftest is currently (v.5.10-rc3) seeing 14 unexpected failures.
Add option to not disable debug_locks, so as to let it reveal any
locking flaws in new unrelated work.
Signed-off-by: Jim Cromie <[email protected]>
---
lib/locking-selftest.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index a899b3f0e2e5..87889bcf3232 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -41,6 +41,20 @@ static int __init setup_debug_locks_verbose(char *str)
__setup("debug_locks_verbose=", setup_debug_locks_verbose);
+/*
+ * proceed thru debug fails, leave debugging enabled
+ */
+static unsigned int debug_locks_proceed;
+
+static int __init setup_debug_locks_proceed(char *str)
+{
+ get_option(&str, &debug_locks_proceed);
+
+ return 1;
+}
+
+__setup("debug_locks_proceed=", setup_debug_locks_proceed);
+
#define FAILURE 0
#define SUCCESS 1
@@ -2480,9 +2494,10 @@ void locking_selftest(void)
if (unexpected_testcase_failures) {
printk("-----------------------------------------------------------------\n");
- debug_locks = 0;
- printk("BUG: %3d unexpected failures (out of %3d) - debugging disabled! |\n",
- unexpected_testcase_failures, testcase_total);
+ debug_locks = debug_locks_proceed;
+ printk("BUG: %3d unexpected failures (out of %3d) - debugging %s! |\n",
+ unexpected_testcase_failures, testcase_total,
+ (!debug_locks_proceed) ? "disabled" : "proceeding anyway");
printk("-----------------------------------------------------------------\n");
} else if (expected_testcase_failures && testcase_successes) {
printk("--------------------------------------------------------\n");
--
2.28.0
On Fri, Nov 13, 2020 at 04:00:48PM -0700, Jim Cromie wrote:
> Locking selftest is currently (v.5.10-rc3) seeing 14 unexpected failures.
> Add option to not disable debug_locks, so as to let it reveal any
> locking flaws in new unrelated work.
I'm assuming this is the arm64 fallout? Mark anything I can do to help
you there?
The reasoning doesn't make sense though; if it can't pass the selftest,
then why would you trust any further reports?
On Tue, Nov 17, 2020 at 3:02 AM Peter Zijlstra <[email protected]> wrote:
>
> On Fri, Nov 13, 2020 at 04:00:48PM -0700, Jim Cromie wrote:
> > Locking selftest is currently (v.5.10-rc3) seeing 14 unexpected failures.
> > Add option to not disable debug_locks, so as to let it reveal any
> > locking flaws in new unrelated work.
>
> I'm assuming this is the arm64 fallout? Mark anything I can do to help
> you there?
>
> The reasoning doesn't make sense though; if it can't pass the selftest,
> then why would you trust any further reports?
because it knows more than I do.
having chosen to proceed anyway,
Im free to discount the advice.