linux-kernel - Re: [PATCH] mm: fix finish_fault() handling for large folios

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: <12dfdfde-06db-4112-9979-2ed320f80439@redhat.com>
Date: Wed, 26 Feb 2025 17:52:13 +0100
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Brian Geffon <bgeffon@...gle.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Zi Yan <ziy@...dia.com>,
 Kefeng Wang <wangkefeng.wang@...wei.com>,
 Suren Baghdasaryan <surenb@...gle.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Hugh Dickins
 <hughd@...gle.com>, Marek Maslanka <mmaslanka@...gle.com>
Subject: Re: [PATCH] mm: fix finish_fault() handling for large folios

On 26.02.25 17:28, Matthew Wilcox wrote:
> On Wed, Feb 26, 2025 at 04:42:46PM +0100, David Hildenbrand wrote:
>> On 26.02.25 15:03, Matthew Wilcox wrote:
>>> On Wed, Feb 26, 2025 at 06:48:15AM -0500, Brian Geffon wrote:
>>>> When handling faults for anon shmem finish_fault() will attempt to install
>>>> ptes for the entire folio. Unfortunately if it encounters a single
>>>> non-pte_none entry in that range it will bail, even if the pte that
>>>> triggered the fault is still pte_none. When this situation happens the
>>>> fault will be retried endlessly never making forward progress.
>>>>
>>>> This patch fixes this behavior and if it detects that a pte in the range
>>>> is not pte_none it will fall back to setting just the pte for the
>>>> address that triggered the fault.
>>>
>>> Surely there's a similar problem in do_anonymous_page()?
>>
>> I recall we handle it in there correctly the last time I stared at it.
>>
>> We check pte_none to decide which folio size we can allocate (including
>> basing the decision on other factors like VMA etc), and after retaking the
>> PTL, we recheck vmf_pte_changed / pte_range_none() to make sure there were
>> no races.
> 
> Ah, so then we'll retry and allocate a folio of the right size the next
> time?

IIRC we'll retry the fault in case we had a race. Likely, if we had a 
race, somebody else installed a (large) folio and we essentially have to 
second fault. If, for some reason, the race only touched parts of the 
PTEs we tried to modify, we'll get another fault and allocate something 
(smaller) that would fit into the new empty range.

So yes, we're more flexible because we're allocating the folios and 
don't have to take whatever folio size is in the pagecache in consideration.

-- 
Cheers,

David / dhildenb