From: Alan Stern <stern@rowland.harvard.edu>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: 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>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Boqun Feng <boqun.feng@gmail.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: Sun, 12 Feb 2023 20:23:34 -0500 [thread overview]
Message-ID: <Y+mRFUws3dOpU8qS@rowland.harvard.edu> (raw)
In-Reply-To: <Y+lROV3Ii+WbmZCh@moria.home.lan>
On Sun, Feb 12, 2023 at 03:51:05PM -0500, Kent Overstreet wrote:
> On Sun, Feb 12, 2023 at 03:19:16PM -0500, Alan Stern wrote:
> > I'll revise the patch to use the device's name for the class. While it
> > may not be globally unique, it should be sufficiently specific.
> >
> > (Device names are often set after the device is initialized. Does
> > lockdep mind if a lock_class_key's name is changed after it has been
> > registered?)
>
> The device name should _not_ be something dynamic, it should be
> something easily tied back to a source code location - i.e. related to
> the driver name, not the device name.
>
> That's how people read and use lockdep reports!
>
> Do it exactly the same way mutex_init() does it, just lift it up a level
> to a wrapper around device_initialize() - stringify the pointer to the
> mutex (embedded in struct device, embedded in what-have-you driver code)
> and use that.
I really don't think that's a good idea here. When you've got a bus
containing multiple devices, typically all those device structures are
created by the same line of code. So knowing the source code location
won't tell you _which_ device structure is involved in the locking
cycle or what driver it's using. By contrast, knowing the device name
would.
Furthermore, to the extent that the device's name identifies what kind
of device it is, the name would tell you what where the structure was
created and which driver it is using.
For example, knowing that a struct device was initialized in line 2104
of drivers/usb/core/message.c tells you only that the device is a USB
interface. It doesn't tell you which USB interface. But knowing that
the device's name is 1-7:1.1 not only tells me that the device is a USB
interface, it also allows me to do:
$ ls -l /sys/bus/usb/devices/1-7:1.1/driver
lrwxrwxrwx. 1 root root 0 Feb 12 19:56 /sys/bus/usb/devices/1-7:1.1/driver -> ../../../../../../bus/usb/drivers/usbhid/
telling me that the device is some sort of HID device. Probably my
laptop's touchpad (which could easily be verified). Even without direct
interaction with the system, searching through the kernel log would give
me this information.
> > At this stage, converting would be most impractical. And I don't think
> > it's really needed.
>
> They do make you deal with lock restarts; unwinding typical stateful
> kernel code is not necessarily super practical :)
>
> Anyways, it sounds like the lockdep-class-per-driver approach will get
> you more information, that's certainly a reasonable approach for now.
Thanks for the review and suggestions.
Alan Stern
next prev parent reply other threads:[~2023-02-13 1:23 UTC|newest]
Thread overview: 78+ 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 [this message]
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
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
2023-02-06 2:56 ` Hillf Danton
2023-02-06 4:44 ` Matthew Wilcox
2023-02-06 5:17 ` Greg Kroah-Hartman
2023-02-06 6:43 ` Hillf Danton
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
2023-02-05 0:21 ` Hillf Danton
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+mRFUws3dOpU8qS@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.