linux-kernel - Re: [PATCH] mm/hmm: Do not fault in device private pages owned by the caller

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] [day] [month] [year] [list]

Message-ID: <20250728133440.GB36037@nvidia.com>
Date: Mon, 28 Jul 2025 10:34:40 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Matthew Brost <matthew.brost@...el.com>
Cc: Balbir Singh <balbirs@...dia.com>, leonro@...dia.com,
	Francois Dugast <francois.dugast@...el.com>, airlied@...il.com,
	akpm@...ux-foundation.org, apopple@...dia.com, baohua@...nel.org,
	baolin.wang@...ux.alibaba.com, dakr@...nel.org, david@...hat.com,
	donettom@...ux.ibm.com, jane.chu@...cle.com, jglisse@...hat.com,
	kherbst@...hat.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, lyude@...hat.com, peterx@...hat.com,
	ryan.roberts@....com, shuah@...nel.org, simona@...ll.ch,
	wangkefeng.wang@...wei.com, willy@...radead.org, ziy@...dia.com
Subject: Re: [PATCH] mm/hmm: Do not fault in device private pages owned by
 the caller

On Wed, Jul 23, 2025 at 10:02:58PM -0700, Matthew Brost wrote:
> On Thu, Jul 24, 2025 at 10:25:11AM +1000, Balbir Singh wrote:
> > On 7/23/25 05:34, Francois Dugast wrote:
> > > When the PMD swap entry is device private and owned by the caller,
> > > skip the range faulting and instead just set the correct HMM PFNs.
> > > This is similar to the logic for PTEs in hmm_vma_handle_pte().
> > > 
> > > For now, each hmm_pfns[i] entry is populated as it is currently done
> > > in hmm_vma_handle_pmd() but this might not be necessary. A follow-up
> > > optimization could be to make use of the order and skip populating
> > > subsequent PFNs.
> > 
> > I think we should test and remove these now
> > 
> 
> +Jason, Leon – perhaps either of you can provide insight into why
> hmm_vma_handle_pmd fully populates the HMM PFNs when a higher-order page
> is found.

I'm not sure why this is burined in some weird unrelated thread,
please post patches normally and CC the right people.

At least the main patch looks reasonable to me, and probably should do
pgd as well while at it?

> If we can be assured that changing this won’t break other parts of the
> kernel, I agree it should be removed. A snippet of documentation should
> also be added indicating that when higher-order PFNs are found,
> subsequent PFNs within the range will remain unpopulated. I can verify
> that GPU SVM works just fine without these PFNs being populated.

We can only do this if someone audits all the current users to confirm
they are compatible. Do that and then it is OK to propose the change.

I think the current version evolved as an optimization so I would not
be surprised to see that some callers need fixing.

Jason