[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260116-nvmem-unbind-v1-0-7bb401ab19a8@oss.qualcomm.com>
Date: Fri, 16 Jan 2026 12:01:07 +0100
From: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
To: Srinivas Kandagatla <srini@...nel.org>,
Bartosz Golaszewski <brgl@...nel.org>
Cc: linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Subject: [PATCH 0/7] nvmem: survive unbind with active consumers
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.
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.
Thankfully the design of nvmem is rather sane so it just needs a bit of
encouragement and synchronization.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
---
Bartosz Golaszewski (7):
nvmem: remove unused field from struct nvmem_device
nvmem: return -EOPNOTSUPP to in-kernel users on missing callbacks
nvmem: check the return value of gpiod_set_value_cansleep()
nvmem: simplify locking with guard()
nvmem: remove unneeded __nvmem_device_put()
nvmem: split struct nvmem_device into refcounted and provider-owned data
nvmem: synchronize nvmem device unregistering with SRCU
drivers/nvmem/core.c | 270 +++++++++++++++++++++++++---------------------
drivers/nvmem/internals.h | 18 +++-
2 files changed, 163 insertions(+), 125 deletions(-)
---
base-commit: 79455889ce4668b4239b3ffe97a86b24e99f2d7e
change-id: 20260114-nvmem-unbind-673b52fc84a0
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Powered by blists - more mailing lists