All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Johan Hovold" <johan@kernel.org>,
	"Aaron Tomlin" <atomlin@atomlin.com>,
	"Bradley Morgan" <brads@mainlining.org>,
	"Thierry Reding" <thierry.reding@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Armin Wolf" <W_Armin@gmx.de>, <linux-kernel@vger.kernel.org>,
	<driver-core@lists.linux.dev>,
	<linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
Date: Sun, 27 Sep 2026 12:03:54 +0200	[thread overview]
Message-ID: <DLQ0HUM8AV99.3DNY5MRA2AZSO@kernel.org> (raw)
In-Reply-To: <DLQ0BIYP96RN.Z0L5I17RQMRQ@kernel.org>

On Sun Sep 27, 2026 at 11:55 AM CEST, Danilo Krummrich wrote:
> On Sun Sep 27, 2026 at 10:03 AM CEST, Uwe Kleine-König wrote:
>> Commit fcbfaffee51a ("driver core: add TAINT_FORCED_BIND for when
>> userspace manually messes with devices and drivers") introduced a taint
>> for usage of bind/unbind sysfs files that manually trigger driver probe
>> and remove respectively.
>>
>> For drivers that do their resource management correctly (which is also
>> needed for module unloading) bind and unbind for matching devices are
>> not critical operations. The thing that makes bind and unbind unsafe is
>> that drivers can be forced on devices that originally don't match using
>> driver_override. The result is that e.g. of_device_get_match_data()
>> returns NULL despite all .of_match_table entries having a non-NULL
>> .driver_data member which yields a NULL pointer exception for several
>> drivers. And given that after setting a driver_override a manual bind is
>> only one way a driver can be bound to an unexpected device, a separate
>> taint for such an override is justified.
>>
>> Reviewed-by: Bradley Morgan <brads@mainlining.org>
>> Reviewed-by: Armin Wolf <W_Armin@gmx.de>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Link: https://lore.kernel.org/driver-core/DLIL9H50MALI.3JROXYEEUM3KU@kernel.org/
>
>> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
>> index c51ad96d4de4..7d5dc016a457 100644
>> --- a/drivers/base/bus.c
>> +++ b/drivers/base/bus.c
>> @@ -513,6 +513,7 @@ static ssize_t driver_override_store(struct device *dev,
>>  {
>>  	int ret;
>>  
>> +	add_taint_module(NULL, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
>>  	ret = __device_set_driver_override(dev, buf, count);
>
> There are buses (such as SPI) which unfortunately have to call
> __device_set_driver_override() directly.
>
> I think it would be better to move the taint into __device_set_driver_override()
> and properly document the purpose of __device_set_driver_override().

Of course I meant to say to create a new forwarding function for this purpose,
such that we do not taint for device_set_driver_override().

Maybe device_store_driver_override() or device_set_driver_override_store()?

> It only exists as SPI and AP are a bit special; both print "\n" when
> driver_override is not set, whereas all other buses (and thus the driver-core)
> produce "(null)\n" in this case. I.e. it should never get any new users.
>
> Thanks,
> Danilo


  reply	other threads:[~2026-09-27 10:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27  8:03 [PATCH v2 0/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-27  8:03 ` [PATCH v2 1/2] docs: admin-guide: Handle TAINT_FORCED_BIND when parsing /proc/sys/kernel/tainted Uwe Kleine-König
2026-09-27 16:39   ` Randy Dunlap
2026-09-27  8:03 ` [PATCH v2 2/2] Add TAINT_DRIVER_OVERRIDE for usage of driver_override Uwe Kleine-König
2026-09-27  8:13   ` sashiko-bot
2026-09-27  9:55   ` Danilo Krummrich
2026-09-27 10:03     ` Danilo Krummrich [this message]
2026-09-28  8:50       ` Uwe Kleine-König
2026-09-28  9:17         ` Danilo Krummrich
2026-09-27 16:50     ` Greg Kroah-Hartman
2026-09-27 17:12       ` 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=DLQ0HUM8AV99.3DNY5MRA2AZSO@kernel.org \
    --to=dakr@kernel.org \
    --cc=W_Armin@gmx.de \
    --cc=atomlin@atomlin.com \
    --cc=brads@mainlining.org \
    --cc=dlechner@baylibre.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=thierry.reding@kernel.org \
    --cc=u.kleine-koenig@baylibre.com \
    /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.