public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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