linux-kernel - Re: [RFC PATCH 6/6] mm: Remove device private pages from the physical address space

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: <1d4cb6e3-38d2-45d0-8e27-4f2b9dccd6cf@nvidia.com>
Date: Tue, 2 Dec 2025 13:28:10 +1100
From: Jordan Niethe <jniethe@...dia.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: linux-mm@...ck.org, balbirs@...dia.com, matthew.brost@...el.com,
 akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, david@...hat.com, ziy@...dia.com,
 apopple@...dia.com, lorenzo.stoakes@...cle.com, lyude@...hat.com,
 dakr@...nel.org, airlied@...il.com, simona@...ll.ch, rcampbell@...dia.com,
 mpenttil@...hat.com, willy@...radead.org
Subject: Re: [RFC PATCH 6/6] mm: Remove device private pages from the physical
 address space

Hi,

On 29/11/25 04:51, Jason Gunthorpe wrote:
> On Fri, Nov 28, 2025 at 03:41:46PM +1100, Jordan Niethe wrote:
>> Introduce helpers:
>>
>>    - device_private_page_to_offset()
>>    - device_private_folio_to_offset()
>>
>> to take a given device private page / folio and return its offset within
>> the device private address space (this is essentially a PFN within the
>> device private address space).
> 
> It would be nice if we rarely/never needed to see number space outside
> the pte itself or the internal helpers..

Outside of the PTE itself, one of the use cases for the PFNs themselves
is range checking. Like we see in mm/page_vma_mapped.c:check_pte().

> 
> Like, I don't think there should be stuff like this:
> 
>>   					entry = make_writable_migration_device_private_entry(
>> -								page_to_pfn(page));
>> +								device_private_page_to_offset(page));
> 
> make_writable_migration_device_private_entry() should accept the
> struct page as the handle?

That would be more clean - I'll give it a try.

> 
> If it really is needed I think it should have its own dedicated type
> and not be intermixed with normal pfns..

One consideration here is for things like range checking the PFNs, the
logic remains the same for device PFNs and the normal PFNs.
If we represent the device PFNs as a unique type, ideally we'd like to
still avoid introducing too much special handling.

Potentially I could see something like a tagged union for memory indices 
like ...

enum memory_index_type {
         MEMORY_INDEX_TYPE_PFN,
         MEMORY_INDEX_TYPE_DEVICE_MEMORY_INDEX,
};

union memory_index {
         unsigned long pfn;
         unsigned long device_memory_index;
         enum memory_index_type type;
};

... if we wanted to introduce a dedicated type.

Another possibility could be to avoid exposing the PFN for cases like
this.

For example if we went back to struct page_vma_mapped_walk containing a
folio / struct page instead of a passing in a pfn then we could 
introduce some helper
like ...

         bool swap_entry_contains_folio(struct folio *folio, swp_entry_t 
entry);

... that handles both device memory and normal memory and use that in
check_pte().

Thanks,
Jordan.

> 
> Jason