From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-nvdimm@lists.01.org, Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH v2 7/7] driver-core, libnvdimm: Let device subsystems add local lockdep coverage
Date: Thu, 18 Jul 2019 11:28:19 +0900 [thread overview]
Message-ID: <20190718022819.GA15376@kroah.com> (raw)
In-Reply-To: <156341210661.292348.7014034644265455704.stgit@dwillia2-desk3.amr.corp.intel.com>
On Wed, Jul 17, 2019 at 06:08:26PM -0700, Dan Williams 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.
>
> Yes, this is a hack, but hopefully it is a useful hack for other
> subsystems device_lock() debug sessions. Quoting Greg:
>
> "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."
Sure, apeal to my vanity and quote me in the changelog, it's as if you
are making it trivial for me to ack this...
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:)
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-nvdimm@lists.01.org, Ingo Molnar <mingo@redhat.com>,
Ira Weiny <ira.weiny@intel.com>,
Will Deacon <will.deacon@arm.com>,
Dave Jiang <dave.jiang@intel.com>,
Keith Busch <keith.busch@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Vishal Verma <vishal.l.verma@intel.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] driver-core, libnvdimm: Let device subsystems add local lockdep coverage
Date: Thu, 18 Jul 2019 11:28:19 +0900 [thread overview]
Message-ID: <20190718022819.GA15376@kroah.com> (raw)
In-Reply-To: <156341210661.292348.7014034644265455704.stgit@dwillia2-desk3.amr.corp.intel.com>
On Wed, Jul 17, 2019 at 06:08:26PM -0700, Dan Williams 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.
>
> Yes, this is a hack, but hopefully it is a useful hack for other
> subsystems device_lock() debug sessions. Quoting Greg:
>
> "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."
Sure, apeal to my vanity and quote me in the changelog, it's as if you
are making it trivial for me to ack this...
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:)
next prev parent reply other threads:[~2019-07-18 2:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-18 1:07 [PATCH v2 0/7] libnvdimm: Fix async operations and locking Dan Williams
2019-07-18 1:07 ` Dan Williams
2019-07-18 1:07 ` [PATCH v2 1/7] drivers/base: Introduce kill_device() Dan Williams
2019-07-18 1:07 ` Dan Williams
2019-07-18 2:29 ` Greg Kroah-Hartman
2019-07-18 2:29 ` Greg Kroah-Hartman
[not found] ` <156341207332.292348.14959761496009347574.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-07-19 0:45 ` Sasha Levin
2019-07-18 1:07 ` [PATCH v2 2/7] libnvdimm/bus: Prevent duplicate device_unregister() calls Dan Williams
2019-07-18 1:07 ` Dan Williams
2019-07-18 1:08 ` [PATCH v2 3/7] libnvdimm/region: Register badblocks before namespaces Dan Williams
2019-07-18 1:08 ` Dan Williams
2019-07-18 18:16 ` Verma, Vishal L
2019-07-18 18:16 ` Verma, Vishal L
2019-07-18 1:08 ` [PATCH v2 4/7] libnvdimm/bus: Prepare the nd_ioctl() path to be re-entrant Dan Williams
2019-07-18 1:08 ` Dan Williams
2019-07-18 18:21 ` Verma, Vishal L
2019-07-18 18:21 ` Verma, Vishal L
2019-07-18 1:08 ` [PATCH v2 5/7] libnvdimm/bus: Stop holding nvdimm_bus_list_mutex over __nd_ioctl() Dan Williams
2019-07-18 1:08 ` Dan Williams
2019-07-18 1:08 ` [PATCH v2 6/7] libnvdimm/bus: Fix wait_nvdimm_bus_probe_idle() ABBA deadlock Dan Williams
2019-07-18 1:08 ` Dan Williams
2019-07-18 2:04 ` Sasha Levin
2019-07-18 2:04 ` Sasha Levin
2019-07-18 6:39 ` Dan Williams
2019-07-18 6:39 ` Dan Williams
2019-07-18 1:08 ` [PATCH v2 7/7] driver-core, libnvdimm: Let device subsystems add local lockdep coverage Dan Williams
2019-07-18 1:08 ` Dan Williams
2019-07-18 2:28 ` Greg Kroah-Hartman [this message]
2019-07-18 2:28 ` Greg Kroah-Hartman
2019-07-18 16:09 ` Ira Weiny
2019-07-18 16:09 ` Ira Weiny
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=20190718022819.GA15376@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=dan.j.williams@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=will.deacon@arm.com \
/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.