[PATCH v2 03/11] mm: introduce pfnmap_track() and pfnmap_untrack() and use them for memremap

David Hildenbrand david at redhat.com
Wed May 14 17:57:29 UTC 2025


On 13.05.25 19:40, Liam R. Howlett wrote:
> * David Hildenbrand <david at redhat.com> [250512 08:34]:
>> Let's provide variants of track_pfn_remap() and untrack_pfn() that won't
>> mess with VMAs, and replace the usage in mm/memremap.c.
>>
>> Add some documentation.
>>
>> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes at oracle.com>
>> Acked-by: Ingo Molnar <mingo at kernel.org> # x86 bits
>> Signed-off-by: David Hildenbrand <david at redhat.com>
> 
> Small nit with this one, but either way:
> 
> Reviewed-by: Liam R. Howlett <Liam.Howlett at oracle.com>

Thanks!

[...]

> 
> The other user is pfnmap_track_ctx_alloc() in mm/memory.c which is
> called from remap_pfn_range(), which also has addr.
> 
> Couldn't we just use the address directly?
> 
> I think the same holds for untrack as well.

Hm, conceptually, I want the "pfntrack" interface to consume ... PFNs :)

Actually, I was thinking about converting the "size" parameter to 
nr_pages as well, but decided to leave that for another day.

... because I really should be working on (... checking todo list ...) 
anything else but PAT at this point.

So unless there are strong feelings, I'll leave it that way (the way the 
old interface also used it), and add it to my todo list (either make it 
an address or make size -> nr_pages).

Thanks for all the review Liam!

-- 
Cheers,

David / dhildenb



More information about the Intel-gfx mailing list