Message-ID: <aXDz-G4-Vvf_BLZw@hovoldconsulting.com>
Date: Wed, 21 Jan 2026 16:42:48 +0100
From: Johan Hovold <johan@...nel.org>
To: Bartosz Golaszewski <brgl@...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 08:57:41PM +0100, Bartosz Golaszewski wrote:
> On Tue, Jan 20, 2026 at 11:18 AM Johan Hovold <johan@...nel.org> wrote:

> > > > 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.

Again, driver unbinding (module unloading) is a development tool, if
making it 100% fool proof would require making drivers unmaintainable
while adding enough runtime overhead it *may* simply not be worth it.

And there are other ways to address this without any such costs since in
99.9999% of cases where unbinding makes no sense at all. If you don't
trust yourself from running around unbinding random drivers, you can
even disable unloading completely. And fw_devlink unbinds consumers
before providers. Etc, etc.

Hot-plug is a different issue, and not something new that you've just
discovered. USB serial deals with this since forever and during Project
Ara we quickly learned that most subsystems do not support hot plugging
(for obvious reasons).

But the most relevant issue here is the user-space interface since a
user can keep a file descriptor open indefinitely. And that can
potentially be solved in a generic fashion without messing up every
driver for something that is not a problem in practice.
 
> 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.

Re-read what I just wrote above.

> 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.

That's about tearing down a subtree, where children would be removed
before parents. If we have random links to hotpluggable devices then
that would be an issue, but so far that looks like yet another contrived
example.

> 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.

Don't flatter yourself.

Johan

Powered by blists - more mailing lists