All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Johan Hovold" <johan@kernel.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	<driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>
Subject: Re: [PATCH] driver core: reject devices with unregistered buses
Date: Wed, 29 Apr 2026 13:11:44 +0200	[thread overview]
Message-ID: <DI5LDIQW45PE.LPIWCARJV7WC@kernel.org> (raw)
In-Reply-To: <afHZWasOhRaeBCnt@hovoldconsulting.com>

On Wed Apr 29, 2026 at 12:11 PM CEST, Johan Hovold wrote:
> On Tue, Apr 28, 2026 at 09:09:04PM +0200, Danilo Krummrich wrote:
>> On Mon Apr 27, 2026 at 12:28 PM CEST, Johan Hovold wrote:
>> > Trying to register a device on a bus which has not yet been registered
>> > used to trigger a NULL-pointer dereference, but since the const bus
>> > structure rework registration instead succeeds without the device being
>> > added to the bus.
>> >
>> > Reject devices with unregistered buses to catch any callers that get
>> > the ordering wrong and to handle bus registration failures more
>> > gracefully.
>> >
>> > Fixes: 5221b82d46f2 ("driver core: bus: bus_add/probe/remove_device() cleanups")
>> > Cc: stable@vger.kernel.org	# 6.3
>> 
>> Hm...this sounds like hardening and not like a "real" bug fix. Do you have a
>> specific reason why you added Cc: stable?
>
> It's certainly a bug fix and this change in behaviour was clearly
> unintended.
>
> Any caller getting the ordering wrong would now succeed in registering
> devices, but no driver would ever be bound which is harder to detect
> than the earlier crashes. 
>
> Whether any offenders have snuck in since 6.3 I don't know, but I still
> think this warrants a backport.

I see where you are coming from, and I agree that having an explicit error print
is an improvement over "the device just never got probed".

However, this isn't an actual bug -- it just happens to make a "real" bug less
obvious to catch.

That said, I don't see how this warrants a stable backport, i.e. it doesn't even
fall under the "this could be a problem" or "theoretical bug" category, which
typically are not accepted either.

As mentioned in the other thread, if this was relaxed, I'm happy to hear about
it.

  reply	other threads:[~2026-04-29 11:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 10:28 [PATCH] driver core: reject devices with unregistered buses Johan Hovold
2026-04-28 19:09 ` Danilo Krummrich
2026-04-29 10:11   ` Johan Hovold
2026-04-29 11:11     ` Danilo Krummrich [this message]
2026-04-29 11:33       ` Johan Hovold
2026-04-29 14:52         ` Danilo Krummrich
2026-04-29 15:08           ` Johan Hovold
2026-04-29 15:29             ` Danilo Krummrich
2026-04-29 16:00               ` Johan Hovold
2026-04-29 16:18                 ` Danilo Krummrich

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=DI5LDIQW45PE.LPIWCARJV7WC@kernel.org \
    --to=dakr@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=stable@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.