Re: [PATCH v3] mm/huge_memory: fix folio isn't locked in softleaf_to_folio()

[Jinjiang Tu <tujinjiang@huawei.com>]

在 2026/3/20 16:10, David Hildenbrand (Arm) 写道:
> On 3/20/26 02:52, Jinjiang Tu wrote:
>> 在 2026/3/20 6:51, Andrew Morton 写道:
>>> On Thu, 19 Mar 2026 09:25:41 +0800 Jinjiang Tu <tujinjiang@huawei.com>
>>> wrote:
>>>
>>>> On arm64 server, we found folio that get from migration entry isn't
>>>> locked
>>>> in softleaf_to_folio(). This issue triggers when mTHP splitting and
>>>> zap_nonpresent_ptes() races, and the root cause is lack of memory
>>>> barrier
>>>> in softleaf_to_folio(). The race is as follows:
>>>>
>>>>      CPU0                                             CPU1
>>>>
>>>> deferred_split_scan()                              zap_nonpresent_ptes()
>>>>     lock folio
>>>>     split_folio()
>>>>       unmap_folio()
>>>>         change ptes to migration entries
>>>>       __split_folio_to_order()
>>>> softleaf_to_folio()
>>>>         set flags(including PG_locked) for tail pages    folio =
>>>> pfn_folio(softleaf_to_pfn(entry))
>>>>         smp_wmb()
>>>> VM_WARN_ON_ONCE(!folio_test_locked(folio))
>>>>         prep_compound_page() for tail pages
>>>>
>>>> In __split_folio_to_order(), smp_wmb() guarantees page flags of tail
>>>> pages
>>>> are visible before the tail page becomes non-compound. smp_wmb() should
>>>> be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a
>>>> result, if zap_nonpresent_ptes() accesses migration entry that stores
>>>> tail pfn, softleaf_to_folio() may see the updated compound_head of tail
>>>> page before page->flags.
>>> Please describe the userspace-visible runtime effects of this bug.
>> This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio().
> But the impact is bigger, right, when callers rely on folio_test_anon() etc?

Yes, the impact is unpredictable if CONFIG_DEBUG_VM isn't enabled.

But for stable kernel before v6.19.9, this is a BUG_ON