All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-cxl@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Dave Jiang <dave.jiang@intel.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	"Schofield, Alison" <alison.schofield@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux NVDIMM <nvdimm@lists.linux.dev>
Subject: Re: [PATCH v2 02/12] device-core: Add dev->lock_class to enable device_lock() lockdep validation
Date: Fri, 15 Apr 2022 09:53:48 +0200	[thread overview]
Message-ID: <YlkkjLJg4a+2gqiq@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAPcyv4hwsKCbaxDhAL6LPZQmLZZV2T4wpja+cNZpjy=enR-eYQ@mail.gmail.com>

On Thu, Apr 14, 2022 at 12:43:31PM -0700, Dan Williams wrote:
> On Thu, Apr 14, 2022 at 12:34 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Apr 14, 2022 at 10:17:13AM -0700, Dan Williams wrote:
> >
> > > One more sanity check... So in driver subsystems there are cases where
> > > a device on busA hosts a topology on busB. When that happens there's a
> > > need to set the lock class late in a driver since busA knows nothing
> > > about the locking rules of busB.
> >
> > I'll pretend I konw what you're talking about ;-)
> >
> > > Since the device has a longer lifetime than a driver when the driver
> > > exits it must set dev->mutex back to the novalidate class, otherwise
> > > it sets up a use after free of the static lock_class_key.
> >
> > I'm not following, static storage has infinite lifetime.
> 
> Not static storage in a driver module.
> 
> modprobe -r fancy_lockdep_using_driver.ko
> 
> Any use of device_lock() by the core on a device that a driver in this
> module was driving will de-reference a now invalid pointer into
> whatever memory was vmalloc'd for the module static data.

Ooh, modules (I always, conveniently, forget they exist). Yes, setting a
lock instance from the core kernel to a key that's inside a module and
then taking the module out will be 'interesting'.

Most likely you'll get a splat from lockdep when doing this.

  reply	other threads:[~2022-04-15  7:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13  6:01 [PATCH v2 00/12] device-core: Enable device_lock() lockdep validation Dan Williams
2022-04-13  6:01 ` [PATCH v2 01/12] device-core: Move device_lock() lockdep init to a helper Dan Williams
2022-04-13  6:01 ` [PATCH v2 02/12] device-core: Add dev->lock_class to enable device_lock() lockdep validation Dan Williams
2022-04-13  8:43   ` Peter Zijlstra
2022-04-13 22:01     ` Dan Williams
2022-04-14 10:16       ` Peter Zijlstra
2022-04-14 17:17         ` Dan Williams
2022-04-14 19:33           ` Peter Zijlstra
2022-04-14 19:43             ` Dan Williams
2022-04-15  7:53               ` Peter Zijlstra [this message]
2022-04-13  6:01 ` [PATCH v2 03/12] cxl/core: Refactor a cxl_lock_class() out of cxl_nested_lock() Dan Williams
2022-04-13  9:39   ` Peter Zijlstra
2022-04-13 22:05     ` Dan Williams
2022-04-13  6:01 ` [PATCH v2 04/12] cxl/core: Remove cxl_device_lock() Dan Williams
2022-04-13  6:01 ` [PATCH v2 05/12] cxl/core: Clamp max lock_class Dan Williams
2022-04-13  6:02 ` [PATCH v2 06/12] cxl/core: Use dev->lock_class for device_lock() lockdep validation Dan Williams
2022-04-13  6:02 ` [PATCH v2 07/12] cxl/acpi: Add a device_lock() lock class for the root platform device Dan Williams
2022-04-13  6:02 ` [PATCH v2 08/12] libnvdimm: Refactor an nvdimm_lock_class() helper Dan Williams
2022-04-13  6:02 ` [PATCH v2 09/12] ACPI: NFIT: Drop nfit_device_lock() Dan Williams
2022-04-13  6:02 ` [PATCH v2 10/12] libnvdimm: Drop nd_device_lock() Dan Williams
2022-04-13  6:02 ` [PATCH v2 11/12] libnvdimm: Enable lockdep validation Dan Williams
2022-04-13  6:02 ` [PATCH v2 12/12] device-core: Enable multi-subsystem device_lock() " Dan Williams
2022-04-13 14:02 ` [PATCH v2 00/12] device-core: Enable " Waiman Long

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=YlkkjLJg4a+2gqiq@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=rafael@kernel.org \
    --cc=vishal.l.verma@intel.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.