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@xxxxxxxxxxxxxxxxxxx> 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
