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

[Lance Yang <lance.yang@linux.dev>]

On Fri, Nov 06, 2026 at 01:36:13PM +0100, David Hildenbrand (Arm) 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.

Right, having a PTE table when we check in do_fault_around() doesn't mean
it'll still be there later ;)

>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.

YES, just fall back and let the regular fault handling take over after
leaving RCU.

>This issue should be fairly hard to hit in practice.
>
>Fixes: 1d65b771bc08 ("mm/khugepaged: retract_page_tables() without mmap or vma lock")
>Cc: stable@vger.kernel.org
>Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>---

LGTM1

Reviewed-by: Lance Yang <lance.yang@linux.dev>

Cheers, Lance