mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: Johan Hovold <johan@kernel.org>,
	Aaron Tomlin <atomlin@atomlin.com>,
	Bradley Morgan <brads@mainlining.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Thierry Reding <thierry.reding@kernel.org>,
	David Lechner <dlechner@baylibre.com>,
	linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH] Add TAINT_DRIVER_OVERRIDE for usage of driver_override
Date: Fri, 25 Sep 2026 20:59:09 +0200	[thread overview]
Message-ID: <3a0eb41b-bddf-4d6c-a61d-73bc545d1a51@gmx.de> (raw)
In-Reply-To: <20260925182041.1025371-2-u.kleine-koenig@baylibre.com>

Am 25.09.26 um 20:20 schrieb Uwe Kleine-König:

> 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.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> I first considered to just set TAINT_FORCED_BIND when driver_override is
> written to. But IMHO it's very useful to differentiate for reported bugs
> if bind/unbind was used in combination with driver_override or not.
>
> Also if only bind/unbind was used and driver_override not, a resulting
> problem is worth fixing (opposed to what is considered for
> bind+driver_override).
>
> IMHO it would also be fine to drop TAINT_FORCED_BIND, but let time prove
> how many reports we get with TAINT_FORCED_BIND but without
> TAINT_DRIVER_OVERRIDE.
>
> Best regards
> Uwe

Good idea, lets see if TAINT_FORCED_BIND is really necessary after all.

Reviewed-by: Armin Wolf <W_Armin@gmx.de>

>
>   Documentation/admin-guide/tainted-kernels.rst | 6 +++++-
>   drivers/base/bus.c                            | 1 +
>   include/linux/panic.h                         | 3 ++-
>   include/trace/events/module.h                 | 3 ++-
>   kernel/panic.c                                | 3 ++-
>   tools/debugging/kernel-chktaint               | 8 ++++++++
>   6 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/tainted-kernels.rst b/Documentation/admin-guide/tainted-kernels.rst
> index abbf5e3dd749..75750a9533e9 100644
> --- a/Documentation/admin-guide/tainted-kernels.rst
> +++ b/Documentation/admin-guide/tainted-kernels.rst
> @@ -74,7 +74,7 @@ a particular type of taint. It's best to leave that to the aforementioned
>   script, but if you need something quick you can use this shell command to check
>   which bits are set::
>   
> -	$ for i in $(seq 20); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
> +	$ for i in $(seq 21); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
>   
>   Table for decoding tainted state
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> @@ -103,6 +103,7 @@ Bit  Log  Number   Reason that got the kernel tainted
>    18  _/N   262144  an in-kernel test has been run
>    19  _/J   524288  userspace used a mutating debug operation in fwctl
>    20  _/Y  1048576  device was manually bound or unbound from a driver
> + 21  _/Z  2097152  a driver was forced on a non-matching device
>   ===  ===  =======  ========================================================
>   
>   Note: The character ``_`` is representing a blank in this table to make reading
> @@ -193,3 +194,6 @@ More detailed explanation for tainting
>   
>    20) ``Y`` If userspace wrote to the `bind` or `unbind` sysfs files and
>        successfully bound or removed a device from a driver.
> +
> + 21) ``Z`` If userspace wrote to a `driver_override` sysfs file opening the gate
> +     for unexpected driver binding.
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index c51ad96d4de4..6e91210aab45 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(drv->owner, TAINT_DRIVER_OVERRIDE, LOCKDEP_STILL_OK);
>   	ret = __device_set_driver_override(dev, buf, count);
>   	if (ret)
>   		return ret;
> diff --git a/include/linux/panic.h b/include/linux/panic.h
> index 23976b1dfdb6..e6e24d8afcf7 100644
> --- a/include/linux/panic.h
> +++ b/include/linux/panic.h
> @@ -90,7 +90,8 @@ static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
>   #define TAINT_TEST			18
>   #define TAINT_FWCTL			19
>   #define TAINT_FORCED_BIND		20
> -#define TAINT_FLAGS_COUNT		21
> +#define TAINT_DRIVER_OVERRIDE		21
> +#define TAINT_FLAGS_COUNT		22
>   #define TAINT_FLAGS_MAX			((1UL << TAINT_FLAGS_COUNT) - 1)
>   
>   struct taint_flag {
> diff --git a/include/trace/events/module.h b/include/trace/events/module.h
> index 19df3e39bba4..c7cdb1f53bc6 100644
> --- a/include/trace/events/module.h
> +++ b/include/trace/events/module.h
> @@ -27,7 +27,8 @@ struct module;
>   	{ (1UL << TAINT_FORCED_MODULE),		"F" },		\
>   	{ (1UL << TAINT_CRAP),			"C" },		\
>   	{ (1UL << TAINT_UNSIGNED_MODULE),	"E" },		\
> -	{ (1UL << TAINT_FORCED_BIND),		"Y" })
> +	{ (1UL << TAINT_FORCED_BIND),		"Y" },		\
> +	{ (1UL << TAINT_DRIVER_OVERRIDE),	"Z" })
>   
>   TRACE_EVENT(module_load,
>   
> diff --git a/kernel/panic.c b/kernel/panic.c
> index b824b68fcb08..f5476a61f6f3 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -826,6 +826,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
>   	TAINT_FLAG(TEST,			'N', ' '),
>   	TAINT_FLAG(FWCTL,			'J', ' '),
>   	TAINT_FLAG(FORCED_BIND,			'Y', ' '),
> +	TAINT_FLAG(DRIVER_OVERRIDE,		'Z', ' '),
>   };
>   
>   #undef TAINT_FLAG
> @@ -862,7 +863,7 @@ static void print_tainted_seq(struct seq_buf *s, bool verbose)
>    * exact size is allocated dynamically; the initial buffer remains
>    * as a fallback if allocation fails.
>    *
> - * The verbose taint string currently requires up to 344 characters.
> + * The verbose taint string currently requires up to 364 characters.
>    */
>   #define INIT_TAINT_BUF_MAX 370
>   
> diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
> index d8628be37214..14d8febd6b16 100755
> --- a/tools/debugging/kernel-chktaint
> +++ b/tools/debugging/kernel-chktaint
> @@ -219,6 +219,14 @@ else
>   	addout "Y"
>   	echo " * device was manually bound or unbound from a driver (#20)"
>   fi
> +
> +T=`expr $T / 2`
> +if [ `expr $T % 2` -eq 0 ]; then
> +	addout " "
> +else
> +	addout "Z"
> +	echo " * a driver was forced on a non-matching device (#21)"
> +fi
>   echo "Raw taint value as int/string: $taint/'$out'"
>   
>   # report on any tainted loadable modules

  parent reply	other threads:[~2026-09-25 18:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25 18:20 Uwe Kleine-König
2026-09-25 18:42 ` Bradley Morgan
2026-09-25 18:59 ` Armin Wolf [this message]
2026-09-25 20:28 ` Uwe Kleine-König
2026-09-25 20:30   ` Bradley Morgan

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=3a0eb41b-bddf-4d6c-a61d-73bc545d1a51@gmx.de \
    --to=w_armin@gmx.de \
    --cc=atomlin@atomlin.com \
    --cc=brads@mainlining.org \
    --cc=dakr@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®