linux-kernel - Re: [PATCH] mm/gup: Drain batched mlock folio processing before attempting migration

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: <6a93bf8f-b46f-4c68-a03d-f3a8b2a1589d@nvidia.com>
Date: Tue, 9 Sep 2025 17:24:02 -0700
From: John Hubbard <jhubbard@...dia.com>
To: David Hildenbrand <david@...hat.com>, Will Deacon <will@...nel.org>,
 Hugh Dickins <hughd@...gle.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Keir Fraser <keirf@...gle.com>, Jason Gunthorpe <jgg@...pe.ca>,
 Frederick Mayle <fmayle@...gle.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Peter Xu <peterx@...hat.com>,
 Rik van Riel <riel@...riel.com>, Vlastimil Babka <vbabka@...e.cz>,
 Ge Yang <yangge1116@....com>
Subject: Re: [PATCH] mm/gup: Drain batched mlock folio processing before
 attempting migration

On 9/9/25 4:50 AM, David Hildenbrand wrote:
> On 09.09.25 13:39, Will Deacon wrote:
>> On Fri, Aug 29, 2025 at 08:46:52AM -0700, Hugh Dickins wrote:
>>> On Fri, 29 Aug 2025, Will Deacon wrote:
>>>> On Thu, Aug 28, 2025 at 01:47:14AM -0700, Hugh Dickins wrote:
...
> Migration code itself will retry multiple times, which usually takes 
> care of most races.
> 
> Not all of course.
> 
> Now, I recall John was working on that at some point (I recall an RFC 
> patch, but I might be daydreaming), and I recall discussions at LSF/MM 

Yes. I was trying to improve the gup scenario of "try to long-term pin
pages that are currently in ZONE_MOVABLE, and must therefore be migrated
before pinning them". The problem is that the current code just retries
in a loop, when what we really want is for it to go to sleep and wait
for the pages to become migratable.

Anyway, I had trouble finding something to wait *on*. David here at
the last LSF/MM suggested waiting on a page group, but I only partially
understand the approach--and what really happened is that I am
"temporarily" (for a few years) consumed by this entertaining new
Nova (Rust for Linux) project.

And so I've failed to make any progress there this year.

> around improving handling when we are mixing a flood of short-therm gup 
> with a single long-term gup that wants to migrate these (short-term 
> pinned) pages.
> 
> Essentially, we would have to temporarily prevent new short-term GUP 
> pins in order to make the long-term GUP-pin succeed in migrating the folio.
> 

thanks,
-- 
John Hubbard