From: Johan Hovold <johan@kernel.org>
To: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Cc: Srinivas Kandagatla <srini@kernel.org>,
Bartosz Golaszewski <brgl@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers
Date: Mon, 19 Jan 2026 12:22:15 +0100 [thread overview]
Message-ID: <aW4T52TSgMf1bWJu@hovoldconsulting.com> (raw)
In-Reply-To: <20260116-nvmem-unbind-v1-0-7bb401ab19a8@oss.qualcomm.com>
On Fri, Jan 16, 2026 at 12:01:07PM +0100, Bartosz Golaszewski wrote:
> Nvmem is one of the subsystems vulnerable to object life-time issues.
> The memory nvmem core dereferences is owned by nvmem providers which can
> be unbound at any time and even though nvmem devices themselves are
> reference-counted, there's no synchronization with the provider modules.
>
> This typically is not a problem because thanks to fw_devlink, consumers
> get synchronously unbound before providers but it's enough to pass
> fw_devlink=off over the command line, unbind the nvmem controller with
> consumers still holding references to it and try to read/write in order
> to see fireworks in the kernel log.
Well, don't do that then. Only root can unbind drivers, and we have
things like module references to prevent drivers from being unloaded
while in use.
> User-space can trigger it too if a device (for instance: i2c eeprom on a
> cp2112 USB expander) is unplugged halfway through a long read.
Hotplugging may be a real issue, though. But this can solved at the user
interface level. Did you explore that?
For reference, this is related to the i2c discussion here:
https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/
Johan
next prev parent reply other threads:[~2026-01-19 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 11:01 [PATCH 0/7] nvmem: survive unbind with active consumers Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 1/7] nvmem: remove unused field from struct nvmem_device Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 2/7] nvmem: return -EOPNOTSUPP to in-kernel users on missing callbacks Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 3/7] nvmem: check the return value of gpiod_set_value_cansleep() Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 4/7] nvmem: simplify locking with guard() Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 5/7] nvmem: remove unneeded __nvmem_device_put() Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 6/7] nvmem: split struct nvmem_device into refcounted and provider-owned data Bartosz Golaszewski
2026-01-16 11:01 ` [PATCH 7/7] nvmem: synchronize nvmem device unregistering with SRCU Bartosz Golaszewski
2026-01-21 9:18 ` Bartosz Golaszewski
2026-01-19 11:22 ` Johan Hovold [this message]
2026-01-19 12:43 ` [PATCH 0/7] nvmem: survive unbind with active consumers Bartosz Golaszewski
2026-01-20 10:18 ` Johan Hovold
2026-01-20 19:57 ` Bartosz Golaszewski
2026-01-21 15:42 ` Johan Hovold
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=aW4T52TSgMf1bWJu@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srini@kernel.org \
/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