Re: [PATCH v1] driver core: unbind only the driver whose unbind file was written

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sat, Oct 17, 2026 at 08:24:03AM -0400, Nickolai Zeldovich wrote:
> On Sat, Oct 17, 2026 at 5:49 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > > The pattern is as old as the unbind file: the check was never under the
> > > lock and the release never named the driver.  The locked variant has
> > > existed since commit 4bdb35506b89 ("driver core: Add a wrapper around
> > > __device_release_driver()") added the drv argument to
> > > device_release_driver_internal() for driver_detach(), which has the
> > > same requirement.
> >
> > Because this has always been present, and no one has actually reported
> > this, perhaps it is not really a problem at all?  In other words, what
> > real-life-use requires this?  Again, bind/unbind is for developers only.
> 
> The goal was to pin down a precise spec of what should happen when
> writing a device name A to /sys/bus/B/drivers/D/unbind.  I think the
> intended effect is that it should unbind driver D from device A.  The
> code already has a check that tries to ensure this.  However, the
> check isn't technically enough to achieve this precise effect, in the
> presence of concurrent operations on other cores (like
> binding/unbinding other drivers to the same device).

You can not bind/unbind drivers to the same device at the same time, the
driver core should protect yourself from this, BUT most importantly,
bind/unbind is a "best effort, you keep the pieces of the broken kernel
when something goes wrong".

> It sounds like this level of precise specification under weird
> concurrent operations isn't useful for developer-facing interfaces.

Again no one should be doing this, and if they are, they are root and
can do much worse things :)

> I'll stick to more clear-cut bugs.

Or just prove that this is a real bug please.

> > ...
> > > Found by formal verification of drivers/base/bus.c.
> >
> > Where is the formal verification proof?  Please don't have your LLM
> > claim this without that as it's pointless.
> 
> The intended point was to give some indication of where this patch is
> coming from: it aims to formally prove something about the behavior of
> the kernel, rather than fix any specific issue encountered by a Linux
> user.  There isn't a formal spec for the Linux user-kernel boundary,
> though (as in the above example: what exactly should happen in this
> weird concurrent scenario?), so for many cases I'm trying to infer
> what the expected spec is.

Then why did your LLM say that this was found in this way if that's not
what you really did?

People read what you wrote, you should also do so :)

thanks,

greg k-h