linux-kernel - Re: [PATCH v2] rust: Makefile: bound rustdoc workaround to affected versions

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] [day] [month] [year] [list]

Message-ID: <20260203005627.GB52989@ax162>
Date: Mon, 2 Feb 2026 17:56:27 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: HeeSu Kim <mlksvender@...il.com>, Nicolas Schier <nsc@...nel.org>,
	ojeda@...nel.org, gary@...yguo.net, charmitro@...teo.net,
	a.hindborg@...nel.org, aliceryhl@...gle.com,
	bjorn3_gh@...tonmail.com, boqun@...gle.com, dakr@...nel.org,
	lossin@...nel.org, tmgross@...ch.edu,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2] rust: Makefile: bound rustdoc workaround to affected
 versions

On Mon, Feb 02, 2026 at 05:00:59PM +0100, Miguel Ojeda wrote:
> By the way, I wonder if we would want at least a `rustc-max-version`
> function or instead a range-based one for this sort of test. It is not
> a blocker for this patch, but we may want to limit other workarounds
> too (e.g. the one below this one).
> 
> Cc'ing Kbuild since I don't recall we have that for C compilers, so
> there may be a reason for that.

I don't think there is any particular reason for this. It is probably
more that for C, we generally prefer feature or bug checks in Kconfig to
catch problems or enable features for both compilers when they are
detected or we do the version checks with the actual operators from
Kconfig rather than doing something in Kbuild.

Both a "max" version and a range-based macro make sense to me since the
range-based one could just use the min max macros under the hood.

In lieu of a separate macro, couldn't this still use 'rustc-min-version'
for both parts if it was willing to unwrap the nested ifs (which I find
kind of unreadable in their current form):

  # The bug was fixed in Rust 1.90.0, so only apply for 1.88.x and 1.89.x.
  ifeq ($(call rustc-min-version,108800)_$(call rustc-min-version,109000),y_)
  rustdoc_modifiers_workaround := -Cunsafe-allow-abi-mismatch=fixed-x18
  endif

Cheers,
Nathan