* Re: [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
2026-11-11 3:19 [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order() Zi Yan
@ 2026-11-11 7:31 ` David Hildenbrand (Arm)
2026-11-11 18:06 ` Kiryl Shutsemau
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: David Hildenbrand (Arm) @ 2026-11-11 7:31 UTC (permalink / raw)
To: Zi Yan, Andrew Morton, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Usama Arif, Kiryl Shutsemau, Brendan Jackman,
Johannes Weiner, Ye Liu
Cc: linux-mm, linux-kernel, stable
On 11/11/26 04:19, Zi Yan wrote:
> __split_folio_to_order() calls prep_compound_page() on each new head page
> to create a compound page after clear_compound_head(). prep_compound_page()
> uses non atomic __SetPageHead(). It is mostly OK, since the folio is locked
> and frozen and no one else is supposed to modify the folio's flags.
>
> However, code calling migration_entry_wait() can reach the folio by PFN,
> then access its flags. It is because softleaf_entry_wait_on_locked() used
> by migration_entry_wait() sets PG_waiters concurrently without taking a
> reference and the frozen refcount during split cannot block it. Meanwhile,
> __SetPageHead() does a plain read and write, so PG_waiters atomically set
> by softleaf_entry_wait_on_locked() will be lost if the set happens after
> __SetPageHead()'s read and before its write.
>
> One example code interleaving:
>
> CPU0: __split_folio_to_order(new_order>0) CPU1: do_swap_page()
>
> 1. clear_compound_head(new_head)
> new_head->compound_info = 0
> (page_folio(new_head) == new_head now)
>
> 2. migration_entry_wait()
> softleaf_to_folio(entry)
> page_folio() -> new_head
> (not the old head any more)
>
> 3. prep_compound_page(new_head, new_order)
> __SetPageHead(new_head)
> tmp = new_head->flags.f <-- load; PG_waiters == 0 in tmp
>
> 4. folio_set_waiters(new_head)
> set_bit(PG_waiters, &flags.f)
> enqueue on waitqueue, sleep
>
> 5. new_head->flags.f = tmp | (1UL << PG_head)
> <-- store; overwrites step 4, PG_waiters == 0 again
>
> Later, folio_unlock(new_folio) sees no PG_waiters, skips folio_wake_bit(),
> and CPU1 can remain blocked indefinitely.
>
> Fix it by setting PG_head along with other flags in new_folio->flags before
> smp_wmb() and clear_compound_head(). The remaining compound page metadata
> is set after clear_compound_head(). In that way, after
> clear_compound_head() makes new_folio visible, nothing overwrites the
> PG_waiters from softleaf_entry_wait_on_locked() by modifying
> new_folio->flags non-atomically.
>
> While at it, use data_race() to suppress the KCSAN issue reported by Ye
> Liu's patch (the second Closes) on reading folio->flags in
> __split_folio_to_order().
>
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Reported-by: David Hildenbrand <david@kernel.org>
> Closes: https://lore.kernel.org/all/DMHE8BEEER1H.2BIY52NXATPIA@nvidia.com/
> Reported-by: Ye Liu <ye.liu@linux.dev>
> Closes: https://lore.kernel.org/all/20261029-data_race_huge_mem-v1-1-112e331291c1@linux.dev/
> Fixes: c010d47f107f6 ("mm: thp: split huge page to any lower order pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
> The issue was raised by David when reviewing Ye Liu's "mm/huge_memory: use
> READ_ONCE() when cloning folio flags during split" [1]. This patch also
> supersedes Ye Liu's patch.
>
> [1] https://lore.kernel.org/all/20261029-data_race_huge_mem-v1-1-112e331291c1@linux.dev/
> ---
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
I'll wait a bit for more review and then queue it.
--
Cheers,
David
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
2026-11-11 3:19 [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order() Zi Yan
2026-11-11 7:31 ` David Hildenbrand (Arm)
@ 2026-11-11 18:06 ` Kiryl Shutsemau
2026-11-12 6:56 ` Baolin Wang
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Kiryl Shutsemau @ 2026-11-11 18:06 UTC (permalink / raw)
To: Zi Yan
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Baolin Wang, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Brendan Jackman, Johannes Weiner, Ye Liu, linux-mm, linux-kernel,
stable
On Tue, Nov 10, 2026 at 10:19:25PM -0500, Zi Yan wrote:
> __split_folio_to_order() calls prep_compound_page() on each new head page
> to create a compound page after clear_compound_head(). prep_compound_page()
> uses non atomic __SetPageHead(). It is mostly OK, since the folio is locked
> and frozen and no one else is supposed to modify the folio's flags.
>
> However, code calling migration_entry_wait() can reach the folio by PFN,
> then access its flags. It is because softleaf_entry_wait_on_locked() used
> by migration_entry_wait() sets PG_waiters concurrently without taking a
> reference and the frozen refcount during split cannot block it. Meanwhile,
> __SetPageHead() does a plain read and write, so PG_waiters atomically set
> by softleaf_entry_wait_on_locked() will be lost if the set happens after
> __SetPageHead()'s read and before its write.
>
> One example code interleaving:
>
> CPU0: __split_folio_to_order(new_order>0) CPU1: do_swap_page()
>
> 1. clear_compound_head(new_head)
> new_head->compound_info = 0
> (page_folio(new_head) == new_head now)
>
> 2. migration_entry_wait()
> softleaf_to_folio(entry)
> page_folio() -> new_head
> (not the old head any more)
>
> 3. prep_compound_page(new_head, new_order)
> __SetPageHead(new_head)
> tmp = new_head->flags.f <-- load; PG_waiters == 0 in tmp
>
> 4. folio_set_waiters(new_head)
> set_bit(PG_waiters, &flags.f)
> enqueue on waitqueue, sleep
>
> 5. new_head->flags.f = tmp | (1UL << PG_head)
> <-- store; overwrites step 4, PG_waiters == 0 again
>
> Later, folio_unlock(new_folio) sees no PG_waiters, skips folio_wake_bit(),
> and CPU1 can remain blocked indefinitely.
>
> Fix it by setting PG_head along with other flags in new_folio->flags before
> smp_wmb() and clear_compound_head(). The remaining compound page metadata
> is set after clear_compound_head(). In that way, after
> clear_compound_head() makes new_folio visible, nothing overwrites the
> PG_waiters from softleaf_entry_wait_on_locked() by modifying
> new_folio->flags non-atomically.
>
> While at it, use data_race() to suppress the KCSAN issue reported by Ye
> Liu's patch (the second Closes) on reading folio->flags in
> __split_folio_to_order().
>
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Reported-by: David Hildenbrand <david@kernel.org>
> Closes: https://lore.kernel.org/all/DMHE8BEEER1H.2BIY52NXATPIA@nvidia.com/
> Reported-by: Ye Liu <ye.liu@linux.dev>
> Closes: https://lore.kernel.org/all/20261029-data_race_huge_mem-v1-1-112e331291c1@linux.dev/
> Fixes: c010d47f107f6 ("mm: thp: split huge page to any lower order pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zi Yan <ziy@nvidia.com>
Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
2026-11-11 3:19 [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order() Zi Yan
2026-11-11 7:31 ` David Hildenbrand (Arm)
2026-11-11 18:06 ` Kiryl Shutsemau
@ 2026-11-12 6:56 ` Baolin Wang
2026-11-12 8:27 ` David Hildenbrand (Arm)
2026-11-12 8:28 ` David Hildenbrand
4 siblings, 0 replies; 6+ messages in thread
From: Baolin Wang @ 2026-11-12 6:56 UTC (permalink / raw)
To: Zi Yan, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Nico Pache, Ryan Roberts,
Dev Jain, Barry Song, Lance Yang, Usama Arif, Kiryl Shutsemau,
Brendan Jackman, Johannes Weiner, Ye Liu
Cc: linux-mm, linux-kernel, stable
On 11/11/26 11:19 AM, Zi Yan wrote:
> __split_folio_to_order() calls prep_compound_page() on each new head page
> to create a compound page after clear_compound_head(). prep_compound_page()
> uses non atomic __SetPageHead(). It is mostly OK, since the folio is locked
> and frozen and no one else is supposed to modify the folio's flags.
>
> However, code calling migration_entry_wait() can reach the folio by PFN,
> then access its flags. It is because softleaf_entry_wait_on_locked() used
> by migration_entry_wait() sets PG_waiters concurrently without taking a
> reference and the frozen refcount during split cannot block it. Meanwhile,
> __SetPageHead() does a plain read and write, so PG_waiters atomically set
> by softleaf_entry_wait_on_locked() will be lost if the set happens after
> __SetPageHead()'s read and before its write.
>
> One example code interleaving:
>
> CPU0: __split_folio_to_order(new_order>0) CPU1: do_swap_page()
>
> 1. clear_compound_head(new_head)
> new_head->compound_info = 0
> (page_folio(new_head) == new_head now)
>
> 2. migration_entry_wait()
> softleaf_to_folio(entry)
> page_folio() -> new_head
> (not the old head any more)
>
> 3. prep_compound_page(new_head, new_order)
> __SetPageHead(new_head)
> tmp = new_head->flags.f <-- load; PG_waiters == 0 in tmp
>
> 4. folio_set_waiters(new_head)
> set_bit(PG_waiters, &flags.f)
> enqueue on waitqueue, sleep
>
> 5. new_head->flags.f = tmp | (1UL << PG_head)
> <-- store; overwrites step 4, PG_waiters == 0 again
>
> Later, folio_unlock(new_folio) sees no PG_waiters, skips folio_wake_bit(),
> and CPU1 can remain blocked indefinitely.
>
> Fix it by setting PG_head along with other flags in new_folio->flags before
> smp_wmb() and clear_compound_head(). The remaining compound page metadata
> is set after clear_compound_head(). In that way, after
> clear_compound_head() makes new_folio visible, nothing overwrites the
> PG_waiters from softleaf_entry_wait_on_locked() by modifying
> new_folio->flags non-atomically.
>
> While at it, use data_race() to suppress the KCSAN issue reported by Ye
> Liu's patch (the second Closes) on reading folio->flags in
> __split_folio_to_order().
>
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Reported-by: David Hildenbrand <david@kernel.org>
> Closes: https://lore.kernel.org/all/DMHE8BEEER1H.2BIY52NXATPIA@nvidia.com/
> Reported-by: Ye Liu <ye.liu@linux.dev>
> Closes: https://lore.kernel.org/all/20261029-data_race_huge_mem-v1-1-112e331291c1@linux.dev/
> Fixes: c010d47f107f6 ("mm: thp: split huge page to any lower order pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
Make sense to me.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
2026-11-11 3:19 [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order() Zi Yan
` (2 preceding siblings ...)
2026-11-12 6:56 ` Baolin Wang
@ 2026-11-12 8:27 ` David Hildenbrand (Arm)
2026-11-12 8:28 ` David Hildenbrand
4 siblings, 0 replies; 6+ messages in thread
From: David Hildenbrand (Arm) @ 2026-11-12 8:27 UTC (permalink / raw)
To: Zi Yan, Andrew Morton, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Baolin Wang, Nico Pache, Ryan Roberts, Dev Jain, Barry Song,
Lance Yang, Usama Arif, Kiryl Shutsemau, Brendan Jackman,
Johannes Weiner, Ye Liu
Cc: linux-mm, linux-kernel, stable
On 11/11/26 04:19, Zi Yan wrote:
> __split_folio_to_order() calls prep_compound_page() on each new head page
> to create a compound page after clear_compound_head(). prep_compound_page()
> uses non atomic __SetPageHead(). It is mostly OK, since the folio is locked
> and frozen and no one else is supposed to modify the folio's flags.
>
> However, code calling migration_entry_wait() can reach the folio by PFN,
> then access its flags. It is because softleaf_entry_wait_on_locked() used
> by migration_entry_wait() sets PG_waiters concurrently without taking a
> reference and the frozen refcount during split cannot block it. Meanwhile,
> __SetPageHead() does a plain read and write, so PG_waiters atomically set
> by softleaf_entry_wait_on_locked() will be lost if the set happens after
> __SetPageHead()'s read and before its write.
>
> One example code interleaving:
>
> CPU0: __split_folio_to_order(new_order>0) CPU1: do_swap_page()
>
> 1. clear_compound_head(new_head)
> new_head->compound_info = 0
> (page_folio(new_head) == new_head now)
>
> 2. migration_entry_wait()
> softleaf_to_folio(entry)
> page_folio() -> new_head
> (not the old head any more)
>
> 3. prep_compound_page(new_head, new_order)
> __SetPageHead(new_head)
> tmp = new_head->flags.f <-- load; PG_waiters == 0 in tmp
>
> 4. folio_set_waiters(new_head)
> set_bit(PG_waiters, &flags.f)
> enqueue on waitqueue, sleep
>
> 5. new_head->flags.f = tmp | (1UL << PG_head)
> <-- store; overwrites step 4, PG_waiters == 0 again
>
> Later, folio_unlock(new_folio) sees no PG_waiters, skips folio_wake_bit(),
> and CPU1 can remain blocked indefinitely.
>
> Fix it by setting PG_head along with other flags in new_folio->flags before
> smp_wmb() and clear_compound_head(). The remaining compound page metadata
> is set after clear_compound_head(). In that way, after
> clear_compound_head() makes new_folio visible, nothing overwrites the
> PG_waiters from softleaf_entry_wait_on_locked() by modifying
> new_folio->flags non-atomically.
>
> While at it, use data_race() to suppress the KCSAN issue reported by Ye
> Liu's patch (the second Closes) on reading folio->flags in
> __split_folio_to_order().
>
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Reported-by: David Hildenbrand <david@kernel.org>
> Closes: https://lore.kernel.org/all/DMHE8BEEER1H.2BIY52NXATPIA@nvidia.com/
> Reported-by: Ye Liu <ye.liu@linux.dev>
> Closes: https://lore.kernel.org/all/20261029-data_race_huge_mem-v1-1-112e331291c1@linux.dev/
> Fixes: c010d47f107f6 ("mm: thp: split huge page to any lower order pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
2026-11-11 3:19 [PATCH v4] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order() Zi Yan
` (3 preceding siblings ...)
2026-11-12 8:27 ` David Hildenbrand (Arm)
@ 2026-11-12 8:28 ` David Hildenbrand
4 siblings, 0 replies; 6+ messages in thread
From: David Hildenbrand @ 2026-11-12 8:28 UTC (permalink / raw)
To: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Baolin Wang, Nico Pache,
Ryan Roberts, Dev Jain, Barry Song, Lance Yang, Usama Arif,
Kiryl Shutsemau, Brendan Jackman, Johannes Weiner, Ye Liu, Zi Yan
Cc: linux-mm, linux-kernel, stable
On Tue, 10 Nov 2026 22:19:25 -0500, Zi Yan wrote:
> __split_folio_to_order() calls prep_compound_page() on each new head page
> to create a compound page after clear_compound_head(). prep_compound_page()
> uses non atomic __SetPageHead(). It is mostly OK, since the folio is locked
> and frozen and no one else is supposed to modify the folio's flags.
>
> However, code calling migration_entry_wait() can reach the folio by PFN,
> then access its flags. It is because softleaf_entry_wait_on_locked() used
> by migration_entry_wait() sets PG_waiters concurrently without taking a
> reference and the frozen refcount during split cannot block it. Meanwhile,
> __SetPageHead() does a plain read and write, so PG_waiters atomically set
> by softleaf_entry_wait_on_locked() will be lost if the set happens after
> __SetPageHead()'s read and before its write.
>
> [...]
Applied, thanks!
tree: mm/core.git
branch: for-next-fixes
Applied patches will appear soon in mm-next, followed by linux-next.
Please report any outstanding bugs that were missed during review, so we
can either drop the patch series or decide how to fix it up.
It is encouraged to provide Acked-bys, Reviewed-bys, and Tested-bys even
though the patches have already been applied. If possible, patch trailers
will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. Further, this is not a guarantee that the
patches will go upstream. If in doubt, please check the listed branch.
[1/1] mm/huge_memory: prevent losing PG_waiters in __split_folio_to_order()
https://git.kernel.org/mm/core/c/0cedfa01
--
Cheers,
David
^ permalink raw reply [flat|nested] 6+ messages in thread