Re: [PATCH 2/3] rust: add kernel taint abstraction

["Gary Guo" <gary@garyguo.net>]

On Mon Oct 19, 2026 at 10:24 PM BST, Danilo Krummrich wrote:
> Allow Rust code to taint the kernel to record conditions that may be
> relevant when diagnosing subsequent kernel failures.
>
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> ---
>  rust/bindings/bindings_helper.h |  1 +
>  rust/kernel/lib.rs              |  1 +
>  rust/kernel/panic.rs            | 50 +++++++++++++++++++++++++++++++++
>  3 files changed, 52 insertions(+)
>  create mode 100644 rust/kernel/panic.rs
>
> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 930e63290cdd..bc248918c99b 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -74,6 +74,7 @@
>  #include <linux/mm.h>
>  #include <linux/miscdevice.h>
>  #include <linux/of_device.h>
> +#include <linux/panic.h>
>  #include <linux/pci.h>
>  #include <linux/phy.h>
>  #include <linux/pid_namespace.h>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index f9ef36217bb5..fd8fe9373401 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -112,6 +112,7 @@
>  #[cfg(CONFIG_PM_OPP)]
>  pub mod opp;
>  pub mod page;
> +pub mod panic;
>  #[cfg(CONFIG_PCI)]
>  pub mod pci;
>  pub mod pid_namespace;
> diff --git a/rust/kernel/panic.rs b/rust/kernel/panic.rs
> new file mode 100644
> index 000000000000..8a78591dfb8a
> --- /dev/null
> +++ b/rust/kernel/panic.rs
> @@ -0,0 +1,50 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +//! Kernel taint tracking.
> +//!
> +//! C header: [`include/linux/panic.h`](srctree/include/linux/panic.h)
> +//!
> +//! See the [tainted-kernels documentation] for the meaning of each taint.
> +//!
> +//! [tainted-kernels documentation]: srctree/Documentation/admin-guide/tainted-kernels.rst
> +
> +/// A reason for tainting the kernel.
> +#[derive(Clone, Copy, Debug, Eq, PartialEq)]
> +#[repr(u32)]
> +pub enum Taint {
> +    /// Tainting was explicitly requested by the user.
> +    User = bindings::TAINT_USER,
> +}
> +
> +impl Taint {
> +    #[inline]
> +    const fn as_raw(self) -> u32 {
> +        self as u32
> +    }
> +}
> +
> +/// Whether lock debugging remains reliable after a tainting event.
> +#[derive(Clone, Copy, Debug, Eq, PartialEq)]
> +#[repr(u32)]
> +pub enum Lockdep {

The plain "Lockdep" is too confusing I think. I think sticking to the C enum
name `LockdepOk` would better.

Alternatively, we can consider just calling it `TaintFlags`?

    struct TaintFlags { ... }

    TaintFlags::lockdep_still_okay()
    TaintFlags::lockdep_now_unreliable()

Best,
Gary

> +    /// Keep lock debugging enabled.
> +    StillOk = bindings::lockdep_ok_LOCKDEP_STILL_OK,
> +}
> +
> +impl Lockdep {
> +    #[inline]
> +    const fn as_raw(self) -> bindings::lockdep_ok {
> +        self as u32
> +    }
> +}
> +
> +/// Adds a kernel taint flag.
> +///
> +/// Taint flags persist until reboot, even if the module that set them is unloaded.
> +/// Use [`Lockdep::StillOk`] when the tainting event does not compromise lock debugging.
> +/// This may panic if the kernel's `panic_on_taint` setting matches a set taint flag.
> +#[inline]
> +pub fn add_taint(flag: Taint, lockdep: Lockdep) {
> +    // SAFETY: `Taint` and `Lockdep` restrict both arguments to valid C API values.
> +    unsafe { bindings::add_taint(flag.as_raw(), lockdep.as_raw()) };
> +}