Messages in this thread | | | Date | Thu, 20 Jun 2019 08:34:08 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 6/6] driver-core, libnvdimm: Let device subsystems add local lockdep coverage |
| |
On Wed, Jun 19, 2019 at 03:21:58PM -0700, Dan Williams wrote: > On Tue, Jun 11, 2019 at 4:40 PM Dan Williams <dan.j.williams@intel.com> wrote: > > > > For good reason, the standard device_lock() is marked > > lockdep_set_novalidate_class() because there is simply no sane way to > > describe the myriad ways the device_lock() ordered with other locks. > > However, that leaves subsystems that know their own local device_lock() > > ordering rules to find lock ordering mistakes manually. Instead, > > introduce an optional / additional lockdep-enabled lock that a subsystem > > can acquire in all the same paths that the device_lock() is acquired. > > > > A conversion of the NFIT driver and NVDIMM subsystem to a > > lockdep-validate device_lock() scheme is included. The > > debug_nvdimm_lock() implementation implements the correct lock-class and > > stacking order for the libnvdimm device topology hierarchy. > > Greg, Peter, > > Any thoughts on carrying this debug hack upstream? The idea being that > it's impossible to enable lockdep for the device_lock() globally, but > a constrained usage of the proposed lockdep_mutex has proven enough to > flush out device_lock deadlocks from libnvdimm. > > It appears one aspect that is missing from this patch proposal is a > mechanism / convention to make sure that lockdep_mutex has constrained > usage for a given kernel build, otherwise it's obviously just as > problematic as device_lock(). Other concerns?
Yeah, it feels a bit hacky but it's really up to a subsystem to mess up using it as much as anything else, so user beware :)
I don't object to it if it makes things easier for you to debug.
thanks,
greg k-h
| |