Re: [PATCH 04/13] mm/migrate_device: allocate THP deferred split heads

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 11 Nov 2026 20:40:17 +0100 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> On 11/11/26 20:30, Kiryl Shutsemau wrote:
> > On Wed, Nov 11, 2026 at 06:13:18PM +0000, Lorenzo Stoakes (ARM) wrote:
> >> From: Josef Bacik <josef@toxicpanda.com>
> >>
> >> A THP that device migration maps into an empty PMD can end up on the wrong
> >> deferred split list when it is later queued for a deferred split.
> >>
> >> This occurs if the memcg has no heads yet (resulting in a warning if
> >> CONFIG_DEBUG_VM is set), where deferred_split_folio() will then queue the
> >> folio on the parent's list.
> >>
> >> Once a later THP fault in the same memcg allocates the heads,
> >> __folio_unqueue_deferred_split() and the split path resolve folio_memcg()
> >> to the memcg's own, now existing, list and take its lock.  They then
> >> list_del_init() a folio that is linked on the parent's list, racing with
> >> anything holding the parent's lock, and both lists' nr_items counts go
> >> wrong.
> >>
> >> Resolve the issue by calling folio_memcg_alloc_deferred() after the charge
> >> in migrate_vma_insert_huge_pmd_page() and falling back like a failed charge
> >> if that fails, as __do_huge_pmd_anonymous_page() does.
> >>
> >> This was originally discovered by code inspection.
> >>
> >> Fixes: fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru")
> >> Cc: <stable@vger.kernel.org>
> >> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> >> [ ljs: tweak commit message, remove unnecessary comment ]
> >> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > 
> > mm-new already has this: "mm/migrate_device: allocate deferred split
> > sublists for new huge folios", same Fixes: tag.
> > 
> > Hm?
> 
> I assume that's one from Andrew that he created after a security report (where I
> was CCed and the reporter didn't follow up), but he never sent it out officially.

oops, that's supposed to be commented out.

> So let's review this one here. It's supposed to go through my tree either way :)

Patches are identical.  So I can say

Tested-by: Andrew Morton <akpm@linux-foundation.org>


Based on Ada's supplied fix and reproducer. The report uses CONFIG_TEST_HMM
and privileged guest setup; ordinary-user reachability through a production
driver has not been established.

Built matching pre-patch and patched 7.4.0-rc1 kernels and ran the same
one-folio HMM migration test in each. The x86-64 KVM guest had 8 GiB RAM,
one virtual NUMA node and four single-threaded vCPUs in one virtual socket.
CONFIG_TEST_HMM, CONFIG_MEMCG, CONFIG_SHRINKER_DEBUG and CONFIG_DEBUG_LIST
were enabled; KASAN was disabled.

Both kernels migrated 512 pages to device memory and one huge folio back.
After a partial unmap, normal THP allocation and freeing the migrated
folio, the pre-patch kernel still reported one deferred-split entry on
the root list. The patched kernel reported no entry. Both one-folio
tests completed without a panic or warning.

In two further bounded pre-patch guest runs, eight migrated folios were
queued on the root deferred-split list. Both runs produced DEBUG_LIST
"list_del corruption" warnings during folio release, with
__folio_unqueue_deferred_split() in the trace. In the second run the
warning occurred during a timed scan/removal trial. Neither run crashed
or hung; no delay or fault injection was needed.

The patched guest did not create misplaced root-list entries, so the
concurrent scan test stopped at its setup check rather than running
identical timed trials. These tests do not establish unprivileged
production-driver reachability or privilege escalation.