linux-kernel - Re: [PATCH 01/31] gpu: nova-core: print FB sizes, along with ranges

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: <DFW61H1H3EES.3109E1KP64IXA@garyguo.net>
Date: Fri, 23 Jan 2026 18:04:47 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "John Hubbard" <jhubbard@...dia.com>, "Gary Guo" <gary@...yguo.net>,
 "Danilo Krummrich" <dakr@...nel.org>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Joel Fernandes"
 <joelagnelf@...dia.com>, "Alistair Popple" <apopple@...dia.com>, "Zhi Wang"
 <zhiw@...dia.com>, "Simona Vetter" <simona@...ll.ch>, "Bjorn Helgaas"
 <bhelgaas@...gle.com>, "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 <nouveau@...ts.freedesktop.org>, <rust-for-linux@...r.kernel.org>, "LKML"
 <linux-kernel@...r.kernel.org>, "Gent Binaku" <binakugent@...il.com>
Subject: Re: [PATCH 01/31] gpu: nova-core: print FB sizes, along with ranges

On Fri Jan 23, 2026 at 3:09 AM GMT, John Hubbard wrote:
> On 1/13/26 6:23 PM, John Hubbard wrote:
>> On 1/13/26 5:28 AM, Gary Guo wrote:
>>> On Wed Dec 3, 2025 at 5:58 AM GMT, John Hubbard wrote:
>> ...
>>>> +pub(crate) struct FbRange(Range<u64>);
>>>
>>> How useful do you think this is in general? Would it make sense to have a
>>> dedicated PhysAddrRange type in kernel crate that provides this feature?
>
> I still like this general direction.
>
>> 
>> Pretty useful. Yes that sounds like a good move. And I see from Miguel's
>> reply that Gent Binaku (+CC) has a patch that proposes adding a 
>> PhysAddrRange. I'll go review it in detail.
>
> (correction: PhysAddr, actually. No PhysAddrRange just yet.) 
>
> OK, I looked into this in some detail. Based on my experience with this
> area in HMM (a linux-mm feature that deals with both CPU and GPU memory
> addresses), I'm pretty solidly convinced that PhysAddr is meant for CPU
> physical addresses.
>
> FbRange, on the other hand, is intended for VRAM (a GPU's dedicated
> memory), which is often in a separate address space. So these should not
> be the same Rust type. We'll likely want separate types for CPU, GPU
> (or "device") memory, and even DMA memory.
>
> In order to avoid seriously derailing the review of this Blackwell
> series, I'm going to continue that thought, in more detail, as part of
> my review of the PhysAddr patch [1].
>
> Meanwhile, I propose letting this aspect of this series remain as-is.

Fair. Although an always u64 type could still be useful in general, just like
drm_buddy/gpu_buddy. I would imagine some accelerator wanting things similar
too.

Of course we can always have this start as Nova-specific and move out as needed.

Best,
Gary

>
>
> [1] https://lore.kernel.org/rust-for-linux/20251122055256.264180-1-binakugent@gmail.com/
>
> thanks,