Re: [PATCH] mm/memory: refactor finish_fault
From: Sarthak Sharma
Date: Thu Jun 25 2026 - 05:27:29 EST
Hi David!
On 6/25/26 2:22 PM, David Hildenbrand (Arm) wrote:
> On 6/24/26 12:20, Sarthak Sharma wrote:
>> finish_fault() currently has a goto fallback implementation
>> where we try to map a large folio with PTEs. If that cannot be
>> installed, we goto fallback and go through the fallback mapping
>> path again. This looks weird and is tough to comprehend.
>>
>> Remove the goto fallback implementation and try to map the
>> whole folio if allowed. If the whole folio cannot be mapped,
>> fall back to single page mapping without repeating the whole
>> function.
>>
>> The cleanup of finish_fault() was suggested by David in [1].
>>
>> [1] https://lore.kernel.org/all/3684c55a-6581-4731-b94a-19526f455a1e@xxxxxxxxxx/
>>
>> Suggested-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>> Signed-off-by: Sarthak Sharma <sarthak.sharma@xxxxxxx>
>> ---
>> Tested this patch by running mm selftests on baseline and patched 7.1
>> kernels. No regressions were observed.
>
> This goes into the right direction, but I think we can do better.
>
> For example, we know that we always have to fallback to a single PTE with
> userfaultfd (incl. not mapping a PMD-sized folio by PMDs).
>
> Let me find some time to play with this myself.
>
I intended this patch to be just a refactor to get rid of the goto
fallback mechanism and make the VMA and PTE table bound checks easier to
read.
But yeah I agree that we can work on cases like you mentioned about
userfaultfd. Thanks for the feedback.