Re: [PATCH v2 2/2] mm: don't allocate a page table under RCU in do_set_pmd()

[David Hildenbrand (Arm)]

On 11/6/26 16:56, Usama Arif wrote:
> On Fri, 06 Nov 2026 13:36:13 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
> 
>> do_fault_around() skips PTE table preallocation when the PMD already points
>> to a PTE table. A concurrent collapse can then retract that table and
>> clear the PMD before filemap_map_pages() locks the new PMD-sized folio.
>>
>> filemap_map_pmd() can then call do_set_pmd() with an empty PMD and no
>> preallocated table. On PowerPC hash MMU, do_set_pmd() then tries
>> allocating a PTE table to deposit. But filemap_map_pmd() calls
>> do_set_pmd() under RCU, so allocating from that context is not good.
>>
>> This race became possible when retract_page_tables() stopped taking the
>> mmap and VMA locks. Previously, those locks excluded retraction while
>> the fault was in progress.
>>
>> Add a may_alloc argument to do_set_pmd() and pass false from
>> filemap_map_pmd(), so we can fail with VM_FAULT_FALLBACK instead of
>> trying to allocate.
>>
>> This issue should be fairly hard to hit in practice.
>>
> 
> Yes, I imagine it was very difficult to reproduce, doing a sleeping
> pte_alloc_one() inside filemap_map_pmd()'s RCU read-side section
> when a concurrent retract_page_tables() empties the PMD. Only
> possible on PowerPC.

Yes. Did I express how much I hate us having to support this ppc handling?

I'll buy you a double digit number of beers if you manage to rip that out ;)

-- 
Cheers,

David