From: Alan Stern <stern@rowland.harvard.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
Hillf Danton <hdanton@sina.com>
Subject: Re: Converting dev->mutex into dev->spinlock ?
Date: Sat, 4 Feb 2023 20:23:58 -0500 [thread overview]
Message-ID: <Y98FLlr7jkiFlV0k@rowland.harvard.edu> (raw)
In-Reply-To: <CAHk-=wjoy=hObTmyRb9ttApjndt0LfqAfv71Cz+hEGrT0cLN+A@mail.gmail.com>
On Sat, Feb 04, 2023 at 12:14:54PM -0800, Linus Torvalds wrote:
> On Sat, Feb 4, 2023 at 12:01 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> >
> > I'm sorry, but that simply is not feasible. It doesn't matter how much
> > you want to do it or feel it is needed; there is no reasonable way to do
> > it. To take just one example, what you are saying implies that when a
> > driver is probed for a device, it would not be allowed to register a
> > child device. That's a ridiculous restriction.
>
> Well, we've worked around that in other places by making the lockdep
> classes for different locks of the same type be different.
>
> So this *could* possibly be solved by lockdep being smarter about
> dev->mutex than just "disable checking entirely".
>
> So maybe the lock_set_novalidate_class() could be something better. It
> _is_ kind of disgusting.
>
> That said, maybe people tried to subclass the locks and failed, and
> that "no validation" is the best that can be done.
>
> But other areas *do* end up spending extra effort to separate out the
> locks (and the different uses of the locks), and I think the
> dev->mutex is one of the few cases that just gives up and says "no
> validation at all".
>
> The other case seems to be the md bcache code.
I suppose we could create separate lockdep classes for every bus_type
and device_type combination, as well as for the different sorts of
devices -- treat things like class devices separately from normal
devices, and so on. But even then there would be trouble.
For example, consider PCI devices and PCI bridges (this sort of thing
happens on other buses too). I don't know the details of how the PCI
subsystem works, but presumably when a bridge is probed, the driver then
probes all the devices on the other side of the bridge while holding the
bridge's lock. Then if one of those devices is another bridge, the same
thing happens recursively, and so on. How would drivers cope with that?
How deep will this nesting go? I doubt that the driver core could take
care of these issues all by itself.
I don't know if the following situation ever happens anywhere, but it
could: Suppose a driver wants to lock several children of some device A.
Providing it already holds A's lock, this is perfectly safe. But how
can we tell lockdep? Even if A belongs to a different lockdep class
from its children, the children would all be in the same class.
What happens when a driver wants to lock both a regular device and its
corresponding class device? Some drivers might acquire the locks in one
order and some drivers in another. Again it's safe, because separate
drivers will never try to lock the same devices, but how do you tell
lockdep about this?
No doubt there are other examples of potential problems. Somebody could
try to implement this kind of approach, but almost certainly it would
lead to tons of false positives.
Alan Stern
next prev parent reply other threads:[~2023-02-05 1:24 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 [this message]
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
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=Y98FLlr7jkiFlV0k@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--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.