linux-kernel - Re: [PATCH 3/6] kbuild: rust: re-run Kconfig if the version text changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240817-heavy-dancing-whale-6ae13d@lindesnes>
Date: Sat, 17 Aug 2024 14:58:21 +0200
From: Nicolas Schier <nicolas@...sle.eu>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org,
	Nathan Chancellor <nathan@...nel.org>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH 3/6] kbuild: rust: re-run Kconfig if the version text
 changes

On Fri, Aug 09, 2024 at 12:11:35AM +0200, Miguel Ojeda wrote:
> Re-run Kconfig if we detect the Rust compiler has changed via the version
> text, like it is done for C.
> 
> Unlike C, and unlike `RUSTC_VERSION`, the `RUSTC_VERSION_TEXT` is kept
> under `depends on RUST`, since it should not be needed unless `RUST`
> is enabled.
> 
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
> ---
> Masahiro: I think leaving the `depends on RUST` in `RUSTC_VERSION` is
> OK, but since this is different from the C side, please let me know if
> you prefer otherwise. Thanks!
> 
>  Makefile     | 5 +++--
>  init/Kconfig | 4 +++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 8ad55d6e7b60..2b5f9f098b6f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -648,9 +648,10 @@ endif
> 
>  # The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
>  # Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> -# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> +# CC_VERSION_TEXT and RUSTC_VERSION_TEXT are referenced from Kconfig (so they need export),
>  # and from include/config/auto.conf.cmd to detect the compiler upgrade.

If you send a v2, mind you consider reformatting so that this comment
block stays <= 80 chars?

>  CC_VERSION_TEXT = $(subst $(pound),,$(shell LC_ALL=C $(CC) --version 2>/dev/null | head -n 1))
> +RUSTC_VERSION_TEXT = $(subst $(pound),,$(shell LC_ALL=C $(RUSTC) --version 2>/dev/null | head -n 1))
> 
>  ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
>  include $(srctree)/scripts/Makefile.clang
> @@ -671,7 +672,7 @@ ifdef config-build
>  # KBUILD_DEFCONFIG may point out an alternative default configuration
>  # used for 'make defconfig'
>  include $(srctree)/arch/$(SRCARCH)/Makefile
> -export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
> +export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT RUSTC_VERSION_TEXT
> 
>  config: outputmakefile scripts_basic FORCE
>  	$(Q)$(MAKE) $(build)=scripts/kconfig $@
> diff --git a/init/Kconfig b/init/Kconfig
> index 2f974f412374..b0238c4b6e79 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1926,7 +1926,9 @@ config RUST
>  config RUSTC_VERSION_TEXT
>  	string
>  	depends on RUST
> -	default "$(shell,LC_ALL=C $(RUSTC) --version 2>/dev/null | head -n 1)"
> +	default "$(RUSTC_VERSION_TEXT)"
> +	help
> +	  See `CC_VERSION_TEXT`.
> 
>  config BINDGEN_VERSION_TEXT
>  	string
> --
> 2.46.0

Do we already support rust in external kernel modules?  In top-level
Makefile's oot-kmod 'prepare' target we check that the compiler
(version) is the same as when the kernel itself was built.  If rust
modules are supported, adding a similar check might be helpful.


Nevertheless,

Reviewed-by: Nicolas Schier <nicolas@...sle.eu>