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: <c1938b35-a9f0-4183-9da4-91f434d49ae2@nvidia.com>
Date: Fri, 9 Jan 2026 10:56:37 +1100
From: Jordan Niethe <jniethe@...dia.com>
To: Felix Kuehling <felix.kuehling@....com>, linux-mm@...ck.org
Cc: 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, jgg@...dia.com, willy@...radead.org,
 linuxppc-dev@...ts.ozlabs.org, intel-xe@...ts.freedesktop.org, jgg@...pe.ca
Subject: Re: [PATCH v2 02/11] drm/amdkfd: Use migrate pfns internally

Hi,

On 9/1/26 09:00, Felix Kuehling wrote:
> 
>> @@ -235,7 +235,7 @@ svm_migrate_addr(struct amdgpu_device *adev, 
>> struct page *page)
>>   {
>>       unsigned long addr;
>> -    addr = page_to_pfn(page) << PAGE_SHIFT;
>> +    addr = (migrate_pfn_from_page(page) >> MIGRATE_PFN_SHIFT) << 
>> PAGE_SHIFT;
>>       return (addr - adev->kfd.pgmap.range.start);
> 
> I guess we rely on the fact that for DEVICE_PRIVATE memory, adev- 
>  >kfd.pgmap.range.start will be 0 after your patch 11. So we don't need 
> a special condition here to handle DEVICE_PRIVATE differently.

Actually pgmap.range.start won't be zero - part of the change to the
memremap_device_private_pagemap() in patch 11 is that range is used as an
output parameter.  It returns the range we allocate for the pagemap from the
device_private_pgmap_tree maple tree, representing "device private address
space".

But it's correct that means we don't need special handling here.

> 
> In general, I like the way you handle mpfns as it keeps all the special 
> casing out of the drivers.

Yeah, it does turn out quite neat.

Thanks for review,
Jordan.

> 
> Regards,
>    Felix
> 
> 



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ