From: Boqun Feng <boqun.feng@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Kent Overstreet <kent.overstreet@linux.dev>,
Kent Overstreet <kent.overstreet@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Coly Li <colyli@suse.de>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
syzkaller <syzkaller@googlegroups.com>,
Dmitry Vyukov <dvyukov@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
Hillf Danton <hdanton@sina.com>
Subject: Re: [PATCH RFC] drivers/core: Replace lockdep_set_novalidate_class() with unique class keys
Date: Mon, 20 Feb 2023 09:32:19 -0800 [thread overview]
Message-ID: <Y/Ouo4Jog4bInO63@boqun-archlinux> (raw)
In-Reply-To: <Y+y3r8Q5GT+oJsvd@hirez.programming.kicks-ass.net>
On Wed, Feb 15, 2023 at 11:45:03AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 14, 2023 at 08:22:28AM -0800, Boqun Feng wrote:
>
> > Ah, right, I was missing the fact that it works with 2 classes...
> >
> > But I think with only one class, the nest_lock() still works, right?
> > In other words, if P and Cn are the same lock class in your example.
After playing with some self test cases, I found I was wrong again ;-(
>
> I don't think so, but I don't think I've carefully considered that case.
>
You are right, the same class case will trigger a DEBUG_LOCKS_WARN_ON()
in the match_held_lock() when releasing the locks.
> > Also seems I gave a wrong answer to Alan, just to clarify, the following
> > is not a deadlock to lockdep:
> >
> > T1:
> > mutex_lock(P)
> > mutex_lock_next_lock(C1, P)
> > mutex_lock_next_lock(C2, P)
> > mutex_lock(B)
> >
> > T2:
> > mutex_lock(P)
> > mutex_lock(B)
> > mutex_lock_next_lock(C1, P)
> > mutex_lock_next_lock(C2, P)
> >
>
> This should in fact complain about a CB-BC deadlock, (but I've not
> tested it, just going on memories of how I implemented it).
>
Yes, confirmed by a selftest.
> > Because of any pair of
> >
> > mutex_lock(L);
> > ... // other locks maybe
> > mutex_lock_nest_lock(M, L);
> >
> > lockdep will not add M into the dependency graph, since it's nested and
> > should be serialized by L.
>
> We do enter M into the dependency graph, but instead ignore M-M
> recursion. Specifically so that we might catch the above deadlock vs B.
Right, I mis-read the code, which suggests I should improve it to help
the future me ;-)
FWIW, the selftests I used are as follow:
Regards,
Boqun
------------------------------->8
diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c
index 8d24279fad05..6aadebad68c1 100644
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -60,6 +60,7 @@ __setup("debug_locks_verbose=", setup_debug_locks_verbose);
#define LOCKTYPE_RTMUTEX 0x20
#define LOCKTYPE_LL 0x40
#define LOCKTYPE_SPECIAL 0x80
+#define LOCKTYPE_NEST 0x100
static struct ww_acquire_ctx t, t2;
static struct ww_mutex o, o2, o3;
@@ -2091,14 +2092,14 @@ static void ww_test_edeadlk_acquire_wrong_slow(void)
ww_mutex_lock_slow(&o3, &t);
}
-static void ww_test_spin_nest_unlocked(void)
+static void nest_test_spin_nest_unlocked(void)
{
spin_lock_nest_lock(&lock_A, &o.base);
U(A);
}
/* This is not a deadlock, because we have X1 to serialize Y1 and Y2 */
-static void ww_test_spin_nest_lock(void)
+static void nest_test_spin_nest_lock(void)
{
spin_lock(&lock_X1);
spin_lock_nest_lock(&lock_Y1, &lock_X1);
@@ -2110,6 +2111,33 @@ static void ww_test_spin_nest_lock(void)
spin_unlock(&lock_X1);
}
+static void nest_test_spin_nest_lock_deadlock(void)
+{
+ nest_test_spin_nest_lock();
+
+ /*
+ * Although above is not a deadlokc, but with the following code, Y1 and
+ * A create a ABBA deadlock.
+ */
+ spin_lock(&lock_X1);
+ spin_lock(&lock_A);
+ spin_lock_nest_lock(&lock_Y1, &lock_X1);
+ spin_lock_nest_lock(&lock_Y2, &lock_X1);
+ spin_unlock(&lock_A);
+ spin_unlock(&lock_Y2);
+ spin_unlock(&lock_Y1);
+ spin_unlock(&lock_X1);
+}
+
+/* Not the supported usage */
+static void nest_test_spin_nest_lock_same_class(void)
+{
+ spin_lock(&lock_X1);
+ spin_lock_nest_lock(&lock_X2, &lock_X1);
+ spin_unlock(&lock_X2);
+ spin_unlock(&lock_X1);
+}
+
static void ww_test_unneeded_slow(void)
{
WWAI(&t);
@@ -2323,14 +2351,6 @@ static void ww_tests(void)
dotest(ww_test_edeadlk_acquire_wrong_slow, FAILURE, LOCKTYPE_WW);
pr_cont("\n");
- print_testname("spinlock nest unlocked");
- dotest(ww_test_spin_nest_unlocked, FAILURE, LOCKTYPE_WW);
- pr_cont("\n");
-
- print_testname("spinlock nest test");
- dotest(ww_test_spin_nest_lock, SUCCESS, LOCKTYPE_WW);
- pr_cont("\n");
-
printk(" -----------------------------------------------------\n");
printk(" |block | try |context|\n");
printk(" -----------------------------------------------------\n");
@@ -2360,6 +2380,27 @@ static void ww_tests(void)
pr_cont("\n");
}
+static void nest_tests(void)
+{
+ printk(" --------------------------------------------------------------------------\n");
+ printk(" | nest lock tests |\n");
+ printk(" -------------------\n");
+ print_testname("spinlock nest unlocked");
+ dotest(nest_test_spin_nest_unlocked, FAILURE, LOCKTYPE_NEST);
+ pr_cont("\n");
+
+ print_testname("spinlock nest test");
+ dotest(nest_test_spin_nest_lock, SUCCESS, LOCKTYPE_NEST);
+ pr_cont("\n");
+ print_testname("spinlock nest test dead lock");
+ dotest(nest_test_spin_nest_lock_deadlock, FAILURE, LOCKTYPE_NEST);
+ pr_cont("\n");
+ print_testname("spinlock nest test dead lock");
+ dotest(nest_test_spin_nest_lock_same_class, FAILURE, LOCKTYPE_NEST);
+ pr_cont("\n");
+
+}
+
/*
* <in hardirq handler>
@@ -2966,6 +3007,8 @@ void locking_selftest(void)
ww_tests();
+ nest_tests();
+
force_read_lock_recursive = 0;
/*
* queued_read_lock() specific test cases can be put here
next prev parent reply other threads:[~2023-02-20 17:32 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-04 13:32 Converting dev->mutex into dev->spinlock ? Tetsuo Handa
2023-02-04 13:47 ` Greg Kroah-Hartman
2023-02-04 14:21 ` Tetsuo Handa
2023-02-04 14:34 ` Greg Kroah-Hartman
2023-02-04 15:16 ` Tetsuo Handa
2023-02-04 15:34 ` Alan Stern
2023-02-04 16:12 ` Tetsuo Handa
2023-02-04 16:27 ` Alan Stern
2023-02-04 17:09 ` Tetsuo Handa
2023-02-04 20:01 ` Alan Stern
2023-02-04 20:14 ` Linus Torvalds
2023-02-05 1:23 ` Alan Stern
2023-02-06 14:13 ` Tetsuo Handa
2023-02-06 15:45 ` Alan Stern
2023-02-07 13:07 ` Tetsuo Handa
2023-02-07 17:46 ` Alan Stern
2023-02-07 22:17 ` Tetsuo Handa
2023-02-08 0:34 ` Alan Stern
[not found] ` <20230208080739.1649-1-hdanton@sina.com>
2023-02-08 10:30 ` [PATCH] drivers/core: Replace lockdep_set_novalidate_class() with unique class keys Tetsuo Handa
2023-02-08 15:07 ` Alan Stern
2023-02-09 0:22 ` Tetsuo Handa
2023-02-09 0:46 ` Linus Torvalds
2023-02-09 1:50 ` Tetsuo Handa
2023-02-09 2:26 ` Alan Stern
2023-02-11 2:04 ` Tetsuo Handa
2023-02-11 21:41 ` [PATCH RFC] " Alan Stern
2023-02-11 21:51 ` Linus Torvalds
2023-02-11 23:06 ` Kent Overstreet
2023-02-11 23:08 ` Kent Overstreet
2023-02-11 23:24 ` Kent Overstreet
2023-02-12 2:40 ` Alan Stern
2023-02-12 2:46 ` Kent Overstreet
2023-02-12 3:03 ` Alan Stern
2023-02-12 3:10 ` Kent Overstreet
2023-02-12 15:23 ` Alan Stern
2023-02-12 19:14 ` Kent Overstreet
2023-02-12 20:19 ` Alan Stern
2023-02-12 20:51 ` Kent Overstreet
2023-02-13 1:23 ` Alan Stern
2023-02-13 2:21 ` Kent Overstreet
2023-02-13 15:25 ` Alan Stern
2023-02-13 9:29 ` Peter Zijlstra
2023-02-13 9:27 ` Peter Zijlstra
2023-02-13 15:28 ` Alan Stern
2023-02-13 16:36 ` Peter Zijlstra
2023-02-13 9:24 ` Peter Zijlstra
2023-02-13 15:25 ` Alan Stern
2023-02-13 16:29 ` Peter Zijlstra
2023-02-14 1:51 ` Boqun Feng
2023-02-14 1:53 ` Boqun Feng
2023-02-14 2:03 ` Alan Stern
2023-02-14 2:09 ` Boqun Feng
[not found] ` <20230214052733.3354-1-hdanton@sina.com>
2023-02-14 5:55 ` Boqun Feng
2023-02-14 10:48 ` Peter Zijlstra
2023-02-14 16:22 ` Boqun Feng
2023-02-15 10:45 ` Peter Zijlstra
2023-02-20 17:32 ` Boqun Feng [this message]
2023-02-13 18:46 ` Kent Overstreet
2023-02-14 11:05 ` Peter Zijlstra
2023-02-14 20:05 ` Alan Stern
2023-02-15 10:33 ` Peter Zijlstra
2023-02-14 20:16 ` Kent Overstreet
[not found] ` <20230212013220.2678-1-hdanton@sina.com>
2023-02-12 1:52 ` Kent Overstreet
2023-02-13 9:49 ` Peter Zijlstra
2023-02-13 16:18 ` Alan Stern
2023-02-13 17:51 ` Greg Kroah-Hartman
2023-02-13 18:05 ` Alan Stern
2023-02-05 1:31 ` Converting dev->mutex into dev->spinlock ? Tetsuo Handa
2023-02-05 16:46 ` Alan Stern
[not found] ` <20230206025629.1786-1-hdanton@sina.com>
2023-02-06 4:44 ` Matthew Wilcox
2023-02-06 5:17 ` Greg Kroah-Hartman
[not found] ` <20230206064305.1838-1-hdanton@sina.com>
2023-02-06 6:48 ` Greg Kroah-Hartman
2023-02-04 15:12 ` Alan Stern
2023-02-04 15:30 ` Tetsuo Handa
2023-02-04 15:40 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/Ouo4Jog4bInO63@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=colyli@suse.de \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=kent.overstreet@gmail.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=syzkaller@googlegroups.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox