linux-kernel - Re: [PATCH v2 0/7] rust: build_assert: document and fix use with function arguments

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: <DEO9A3YCUEBI.XTTH17KQLWP4@nvidia.com>
Date: Wed, 03 Dec 2025 12:19:49 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>, "Daniel Almeida"
 <daniel.almeida@...labora.com>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Danilo Krummrich"
 <dakr@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>, "Miguel Ojeda"
 <ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun Feng"
 <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Trevor
 Gross" <tmgross@...ch.edu>, "Rafael J. Wysocki" <rafael@...nel.org>,
 "Viresh Kumar" <viresh.kumar@...aro.org>, "Will Deacon" <will@...nel.org>,
 "Peter Zijlstra" <peterz@...radead.org>, "Mark Rutland"
 <mark.rutland@....com>, <rust-for-linux@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v2 0/7] rust: build_assert: document and fix use with
 function arguments

On Mon Dec 1, 2025 at 2:48 AM JST, Miguel Ojeda wrote:
> On Sun, Nov 30, 2025 at 5:09 PM Daniel Almeida
> <daniel.almeida@...labora.com> wrote:
>>
>> Ah, should this have a Fixes: tag?
>
> Yes for those that trigger an error, e.g. the `Bounded` one with -Os
> in mainline soon. We probably want Cc: stable@ too -- it is not too
> risky to add these anyway.
>
> However, the tag should be different for each commit depending on
> where each method was introduced. #1 and #7 are not really fixes, so
> they don't need it.

Shall I respin with some `Fixes:` tags where appropriate then?