Message-ID: <CAMRc=MdX8zaSXKFi-cLvVOnZwxg5EodTyGaCzW6DyXVpr8-bxA@mail.gmail.com>
Date: Tue, 20 Jan 2026 20:57:41 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, 
	Srinivas Kandagatla <srini@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers

On Tue, Jan 20, 2026 at 11:18 AM Johan Hovold <johan@...nel.org> wrote:
>

[snip to avoid more bickering]

>
> > Also: sysfs attributes don't take a module reference. Unloading an
> > nvmem module during a long read from user-space is equivalent to a USB
> > unplug.
>
> Sysfs will drain any ongoing operations before deregistering, so not
> sure what you're referring to here.
>

True, sysfs will wait for the current operation to complete when
removing attributes but currently you can still very easily trigger a
use-after-free splat from user-space with nvmem the way I described
due to ordering of the teardown. But fair enough - this is an nvmem
problem, not sysfs.

> > > For reference, this is related to the i2c discussion here:
> > >
> > >         https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/
> > >
> >
> > Your argument against the i2c changes is that they affect lots of
> > drivers and decrease readability. I can see it as a point worth
> > considering. In the end it's up to Wolfram to decide and I think he
> > was pretty clear he wants it to proceed.
> >
> > This series addresses the unbinding issue entirely within nvmem core,
> > no driver changes are required. It uses SRCU which is very fast in
> > read sections. What exactly is your argument against it? What is the
> > reason for your comment? Unless you deal with nvmem internals, you
> > never have to concern yourself with it.
>
> My concern is that you're stuck on the idea of wrapping every access in

"Every access" is an exaggeration.

> the kernel with unnecessary constructs because you seem to think driver
> unbinding is something we need to worry about it. It's not. At least
> not at any cost (readability, maintainability, cognitive load, churn,
> performance, ...).
>

That is simply incorrect. I didn't just suddenly make this up. I
encountered this issue - and subsequently started working on it - in
my work with a client's device based on CP2112 I2C/GPIO USB expander
where unplugging it would either crash the system in GPIO unbind path
or freeze the kernel thread forever waiting for a completion in I2C
unbind path. That's why - contrary to what you're claiming here - we
(the kernel community) *do* care about driver unbinding. I truly can't
comprehend why kernel just easily crashing on what is pretty normal
operation does not seem wrong to you.

Ever since Laurent's first talk about object life-time issues (was
that 2021?), I've discussed this with many people - including key
kernel maintainers like Greg KH. People disagree on ways of fixing
this family of problems (it's not a single bug) but you are quite
literally the only person who says that we should do nothing.

Meanwhile, unbinding may not be a problem until it is. I've had Brian
Masney from Red Hat approach me during LPC in Tokyo because he needs
to be able to unbind a clock driver at runtime. At another conference,
Bootlin had a whole BoF/miniconf about dynamically instantiated and
removed platform devices (this was for cape-like extensions but
unbinding was one of the issues). If you're claiming it's unimportant,
then you're simply wrong.

Feel free to review the patches or point out anything incorrect in the
description of the problem, but please stop commenting under every
related series I post (seriously, did you filter lore by my name to
find this one?), saying "we don't want to do this". The consensus is
that this can and should be fixed. You yourself posted a link to
Wolfram's email saying that much about I2C.

I'll wait for Srini to decide whether he wants this or not.

Thanks,
Bartosz

Powered by blists - more mailing lists