mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	driver-core@lists.linux.dev
Subject: Re: [PATCH v2 02/58] driver core: retain the owner of device release callbacks
Date: Tue, 10 Nov 2026 13:50:49 -0500	[thread overview]
Message-ID: <2026111037-stir-hermit-cb21@gregkh> (raw)
In-Reply-To: <20261110-submit-rawnand-retained-handle-lifetime-v1-v2-2-9137d08f05df@gmail.com>

On Tue, Nov 10, 2026 at 12:44:05AM -0700, James Hilliard wrote:
> Device references can outlive the driver or subsystem operation that
> unregistered the device. A modular release callback needs its code to
> remain loaded until it returns. Dropping its last module reference inside
> the callback permits concurrent unload before the function epilogue has
> finished.
> 
> Add an optional release_owner to struct device. device_initialize() takes
> the reference before the device can be published. The built-in device
> core caches the owner before invoking the release callback and drops the
> reference after the callback returns, allowing the callback to free the
> device itself. This also covers initialized devices that were never added
> and device_add() failures.

Please no, we have tried this in the past and it's not good.  Devices
are data, which is different from code.

> MTD will use this to keep its release callback available after retained
> device references outlive driver unbind.

This isn't a good idea, dig through the archives and see what went wrong
before please.

As a hint, look at networking, no module reference counts anywhere!
That's the proper way to do it.

thanks,

greg k-h

  reply	other threads:[~2026-11-10 18:50 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10  7:44 [PATCH v2 00/58] mtd: rawnand: retain chip and controller state across removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 01/58] nvmem: retain provider context through final device release James Hilliard
2026-11-10  7:44 ` [PATCH v2 02/58] driver core: retain the owner of device release callbacks James Hilliard
2026-11-10 18:50   ` Greg Kroah-Hartman [this message]
2026-11-10  7:44 ` [PATCH v2 03/58] mtd: add opt-in lifetime ownership for backing objects James Hilliard
2026-11-10  7:44 ` [PATCH v2 04/58] mtd: retain virtual concatenations across component removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 05/58] mtd: rawnand: separate hardware disconnection from cleanup James Hilliard
2026-11-10  7:44 ` [PATCH v2 06/58] mtd: rawnand: share retained chip and controller ownership James Hilliard
2026-11-10  7:44 ` [PATCH v2 07/58] mtd: rawnand: sunxi: retain chip state until the final MTD put James Hilliard
2026-11-10  7:44 ` [PATCH v2 08/58] mtd: rawnand: plat_nand: retain open-handle state on removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 09/58] mtd: rawnand: gpio: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 10/58] mtd: rawnand: stm32_fmc2: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 11/58] mtd: rawnand: denali: retain chips across controller removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 12/58] mtd: rawnand: arasan: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 13/58] mtd: rawnand: mxic: retain open-handle state on removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 14/58] mtd: rawnand: intel: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 15/58] mtd: rawnand: tegra: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 16/58] mtd: rawnand: mtk: retain chips across controller removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 17/58] mtd: rawnand: rockchip: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 18/58] mtd: rawnand: atmel: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 19/58] mtd: rawnand: orion: retain open-handle state on removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 20/58] mtd: rawnand: socrates: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 21/58] mtd: rawnand: fsl_upm: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 22/58] mtd: rawnand: pasemi: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 23/58] mtd: rawnand: ams-delta: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 24/58] mtd: rawnand: xway: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 25/58] mtd: rawnand: hisi504: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 26/58] mtd: rawnand: vf610: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 27/58] mtd: rawnand: technologic: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 28/58] mtd: rawnand: loongson: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 29/58] mtd: rawnand: ma35d1: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 30/58] mtd: rawnand: pl35x: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 31/58] mtd: rawnand: mxc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 32/58] mtd: rawnand: fsmc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 33/58] mtd: rawnand: gpmi: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 34/58] mtd: rawnand: omap2: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 35/58] mtd: rawnand: marvell: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 36/58] mtd: rawnand: renesas: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 37/58] mtd: rawnand: meson: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 38/58] mtd: rawnand: cadence: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 39/58] mtd: rawnand: qcom: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 40/58] mtd: rawnand: cafe: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 41/58] mtd: rawnand: brcmnand: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 42/58] mtd: rawnand: au1550nd: retain chip state across removal James Hilliard
2026-11-10  7:44 ` [PATCH v2 43/58] mtd: rawnand: sharpsl: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 44/58] mtd: rawnand: davinci: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 45/58] mtd: rawnand: sh_flctl: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 46/58] mtd: rawnand: lpc32xx_slc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 47/58] mtd: rawnand: lpc32xx_mlc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 48/58] mtd: rawnand: ndfc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 49/58] mtd: rawnand: txx9ndfmc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 50/58] mtd: rawnand: ingenic: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 51/58] mtd: rawnand: mpc5121: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 52/58] mtd: rawnand: bcm47xxnflash: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 53/58] mtd: rawnand: fsl_elbc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 54/58] mtd: rawnand: fsl_ifc: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 55/58] mtd: rawnand: r852: " James Hilliard
2026-11-10  7:44 ` [PATCH v2 56/58] mtd: rawnand: nandsim: " James Hilliard
2026-11-10  7:45 ` [PATCH v2 57/58] mtd: rawnand: cs553x: " James Hilliard
2026-11-10  7:45 ` [PATCH v2 58/58] mtd: rawnand: diskonchip: " James Hilliard

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=2026111037-stir-hermit-cb21@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=james.hilliard1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rafael@kernel.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®