linux-kernel - Re: [PATCH 17/31] gpu: nova-core: Hopper/Blackwell: calculate reserved FB heap size

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: <DFUECI1MI0DK.35F3O013QHAE2@garyguo.net>
Date: Wed, 21 Jan 2026 16:10:00 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "John Hubbard" <jhubbard@...dia.com>, "Timur Tabi" <ttabi@...dia.com>,
 "dakr@...nel.org" <dakr@...nel.org>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "lossin@...nel.org"
 <lossin@...nel.org>, "a.hindborg@...nel.org" <a.hindborg@...nel.org>,
 "boqun.feng@...il.com" <boqun.feng@...il.com>, "aliceryhl@...gle.com"
 <aliceryhl@...gle.com>, "Zhi Wang" <zhiw@...dia.com>, "simona@...ll.ch"
 <simona@...ll.ch>, "alex.gaynor@...il.com" <alex.gaynor@...il.com>,
 "ojeda@...nel.org" <ojeda@...nel.org>, "tmgross@...ch.edu"
 <tmgross@...ch.edu>, "nouveau@...ts.freedesktop.org"
 <nouveau@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
 <rust-for-linux@...r.kernel.org>, "bjorn3_gh@...tonmail.com"
 <bjorn3_gh@...tonmail.com>, "Edwin Peer" <epeer@...dia.com>,
 "airlied@...il.com" <airlied@...il.com>, "Joel Fernandes"
 <joelagnelf@...dia.com>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
 "gary@...yguo.net" <gary@...yguo.net>, "Alistair Popple"
 <apopple@...dia.com>
Subject: Re: [PATCH 17/31] gpu: nova-core: Hopper/Blackwell: calculate
 reserved FB heap size

On Thu Dec 4, 2025 at 7:34 AM GMT, John Hubbard wrote:
> On 12/3/25 12:48 PM, Timur Tabi wrote:
>> On Tue, 2025-12-02 at 21:59 -0800, John Hubbard wrote:
>>> +#[inline(always)]
>>> +pub(crate) const fn const_align_up<const ALIGN: usize>(value: usize) -> usize {
>>> +    build_assert!(ALIGN.is_power_of_two());
>>> +    (value + (ALIGN - 1)) & !(ALIGN - 1)
>>> +}
>> 
>> So this is just like the issue I'm having with .next_multiple_of() in my patch #10.
>> 
>> Shouldn't you have a check to make sure that value + (ALIGN - 1) doesn't overflow?  Since I need to
>> align up to the nearest const power of two, I could use this function instead of align_up() and
>> avoid testing for an error condition.
>> 
>
> Const items are special: they are evaluated at compile time, rather
> than at runtime. And so this will fail to compile, for values that
> would overflow.
>
> For example:
>
> error[E0080]: evaluation of constant value failed
>     --> drivers/gpu/nova-core/num.rs:226:5
>      |
> 226 |     (value + (ALIGN - 1)) & !(ALIGN - 1)
>      |     ^^^^^^^^^^^^^^^^^^^^^ attempt to compute `usize::MAX + 15_usize`, which would overflow
>      |
> note: inside `const_align_up::<16>`
>     --> drivers/gpu/nova-core/num.rs:226:5
>      |
> 226 |     (value + (ALIGN - 1)) & !(ALIGN - 1)
>      |     ^^^^^^^^^^^^^^^^^^^^^
> note: inside `_OVERFLOW_TEST`
>     --> drivers/gpu/nova-core/num.rs:231:31
>      |
> 231 | const _OVERFLOW_TEST: usize = const_align_up::<16>(usize::MAX);
>      |                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note that this is only true if the function is only ever called from compile
time. If the const function is indeeed used during runtime, you'll lose these
checks (or, depending on Kconfig, get turned into BUG).

Best,
Gary

>
>
> thanks,