FAILED: patch "[PATCH] mm/huge_memory: do not touch frozen folios in deferred_split_isolate()" failed to apply to 6.18-stable tree
Subsystems (3)
Sasha Levin
maintainerThe patch below does not apply to the 6.18-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.18.y
git checkout FETCH_HEAD
git cherry-pick -x 5da8ec3262bbb40f057f3b0dacc18f37bda06f95
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '[email protected]' --subject-prefix 'PATCH 6.18.y' 'HEAD^..'
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From 5da8ec3262bbb40f057f3b0dacc18f37bda06f95 Mon Sep 17 00:00:00 2001
From: "Kiryl Shutsemau (Meta)" <[email protected]>
Date: Mon, 31 Aug 2026 10:15:13 +0100
Subject: [PATCH] mm/huge_memory: do not touch frozen folios in
deferred_split_isolate()
Patch series "Fix deferred_split_isolate() and drop the split workaround", v2.
deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put().
It leads to wrong results when !folio_try_get() was not caused by folio_put(): for a frozen folio, PG_partially_mapped gets wrongfully cleared and the folio dropped from the queue.
It came up in the review of my collapse RFC series:
https://lore.kernel.org/all/[email protected]/
The bug is inert in upstream code:
- __folio_split() works around it;
- __folio_migrate_mapping() freezes a folio it is about to replace;
- reclaim freezes only what try_to_unmap() already unmapped.
No cc:stable needed. But my collapse rework steps on it, so it is worth fixing.
The branch the first patch removes also hid an inert, pre-existing bug in the zone device path:
https://lore.kernel.org/all/[email protected]/
The first patch fixes deferred_split_isolate().
The second patch removes the workaround for this deferred_split_isolate() behaviour from __folio_freeze_and_split_unmapped().
Tested in a VM: split_huge_page_test, folio_split_race_test and cow pass.
Also ran a test that leaves 16 partially mapped THPs on the deferred split queue and drives thp-deferred_split through debugfs, checking nr_anon_partially_mapped.
This patch (of 2):
deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put(): clear PG_partially_mapped, correct MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, take the folio off the queue.
The folio_put() race is the most common case for !folio_try_get(), but it is not the only option. Another scenario is folio_ref_freeze().
A zero refcount in such cases does not mean the folio is going away. It means "don't touch me" and current deferred_split_isolate() doesn't respect it. It can lead to unqueueing folios from the deferred list for no reason:
CPU 0 CPU 1
--------------------------- ------------------------------
freeze a mapped folio deferred_split_scan() folio_ref_freeze() folio_try_get() fails
folio_clear_partially_mapped() NR_ANON_PARTIALLY_MAPPED-- folio off the queue
give up, put it back
folio_ref_unfreeze()
The folio is still partially mapped, but it is no longer a split candidate. Nothing queues it again until part of it is unmapped once more.
Skip the folio instead: whoever freezes the folio, owns it and owner is responsible for its fate. It also covers the folio_put() case:__folio_put() unqueues the folio via folio_unqueue_deferred_split().
Nothing is lost by skipping. Everything that frees a queued folio unqueues it first, and folio_unqueue_deferred_split() clears PG_partially_mapped and brings MTHP_STAT_NR_ANON_PARTIALLY_MAPPED down on the way:
__folio_put(), folios_put_refs() mm/folio.c
__folio_migrate_mapping() mm/migrate.c
shrink_folio_list() mm/vmscan.c__folio_freeze_and_split_unmapped() does the same by hand, under the list_lru lock it holds across the freeze. A freeze that ends in folio_ref_unfreeze() leaves a folio that is still partially mapped and still belongs on the queue.
--- mm/huge_memory.c | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-)
mm/huge_memory.c +4 -15
@@ -4638,22 +4638,11 @@ static enum lru_status deferred_split_isolate(struct list_head *item, struct folio *folio = container_of(item, struct folio, _deferred_list);struct list_head *freeable = cb_arg; -if (folio_try_get (folio)) { -list_lru_isolate_move (lru, item, freeable); -return LRU_REMOVED ; - } +/* Lost race to folio_put() or the folio is under folio_ref_freeze() */ +if (!folio_try_get (folio)) +return LRU_SKIP ; -/* -* We lost race with folio_put(). Read folio state before the -* isolate: folio_unqueue_deferred_split() checks list_empty() -* locklessly, so once removed the folio can be freed any time. -*/ -if (folio_test_partially_mapped (folio)) { -folio_clear_partially_mapped (folio); -mod_mthp_stat (folio_order (folio), -MTHP_STAT_NR_ANON_PARTIALLY_MAPPED ,-1 ); - } -list_lru_isolate (lru, item); +list_lru_isolate_move (lru, item, freeable);return LRU_REMOVED ; }
Signature · 1 line
2.53.0
Sasha Levin
maintainerPATCH 1/1 mm/huge_memory: do not touch frozen folios in deferred_split_isolate()
From: "Kiryl Shutsemau (Meta)" <[email protected]>
[ Upstream commit 5da8ec3262bbb40f057f3b0dacc18f37bda06f95 ]
Patch series "Fix deferred_split_isolate() and drop the split workaround", v2.
deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put().
It leads to wrong results when !folio_try_get() was not caused by folio_put(): for a frozen folio, PG_partially_mapped gets wrongfully cleared and the folio dropped from the queue.
It came up in the review of my collapse RFC series:
https://lore.kernel.org/all/[email protected]/
The bug is inert in upstream code:
- __folio_split() works around it;
- __folio_migrate_mapping() freezes a folio it is about to replace;
- reclaim freezes only what try_to_unmap() already unmapped.
No cc:stable needed. But my collapse rework steps on it, so it is worth fixing.
The branch the first patch removes also hid an inert, pre-existing bug in the zone device path:
https://lore.kernel.org/all/[email protected]/
The first patch fixes deferred_split_isolate().
The second patch removes the workaround for this deferred_split_isolate() behaviour from __folio_freeze_and_split_unmapped().
Tested in a VM: split_huge_page_test, folio_split_race_test and cow pass.
Also ran a test that leaves 16 partially mapped THPs on the deferred split queue and drives thp-deferred_split through debugfs, checking nr_anon_partially_mapped.
This patch (of 2):
deferred_split_isolate() probes each queued folio with folio_try_get(). folio_try_get() failure is treated as a lost race with folio_put(): clear PG_partially_mapped, correct MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, take the folio off the queue.
The folio_put() race is the most common case for !folio_try_get(), but it is not the only option. Another scenario is folio_ref_freeze().
A zero refcount in such cases does not mean the folio is going away. It means "don't touch me" and current deferred_split_isolate() doesn't respect it. It can lead to unqueueing folios from the deferred list for no reason:
CPU 0 CPU 1
--------------------------- ------------------------------
freeze a mapped folio deferred_split_scan() folio_ref_freeze() folio_try_get() fails
folio_clear_partially_mapped() NR_ANON_PARTIALLY_MAPPED-- folio off the queue
give up, put it back
folio_ref_unfreeze()
The folio is still partially mapped, but it is no longer a split candidate. Nothing queues it again until part of it is unmapped once more.
Skip the folio instead: whoever freezes the folio, owns it and owner is responsible for its fate. It also covers the folio_put() case:__folio_put() unqueues the folio via folio_unqueue_deferred_split().
Nothing is lost by skipping. Everything that frees a queued folio unqueues it first, and folio_unqueue_deferred_split() clears PG_partially_mapped and brings MTHP_STAT_NR_ANON_PARTIALLY_MAPPED down on the way:
__folio_put(), folios_put_refs() mm/folio.c
__folio_migrate_mapping() mm/migrate.c
shrink_folio_list() mm/vmscan.c__folio_freeze_and_split_unmapped() does the same by hand, under the list_lru lock it holds across the freeze. A freeze that ends in folio_ref_unfreeze() leaves a folio that is still partially mapped and still belongs on the queue.
--- mm/huge_memory.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
mm/huge_memory.c +2 -7
@@ -4310,14 +4310,9 @@ static unsigned long deferred_split_scan(struct shrinker *shrink, _deferred_list) {if (folio_try_get (folio)) {folio_batch_add (&fbatch, folio); - }else if (folio_test_partially_mapped (folio)) { -/* We lost race with folio_put() */ -folio_clear_partially_mapped (folio); -mod_mthp_stat (folio_order (folio), -MTHP_STAT_NR_ANON_PARTIALLY_MAPPED ,-1 ); +list_del_init (&folio->_deferred_list); + ds_queue->split_queue_len--; } -list_del_init (&folio->_deferred_list); - ds_queue->split_queue_len--;if (!--sc->nr_to_scan)break ;if (!folio_batch_space (&fbatch))
Signature · 1 line
2.53.0