Re: [PATCH 1/2] mm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] `free_zone_device_folio()` bypasses `folio_unqueue_deferred_split()`, causing list corruption on the deferred split LRU, leaking `MTHP_STAT_NR_ANON_PARTIALLY_MAPPED`, and triggering a `WARN_ON_ONCE`.
--

commit e9684c49325471cce57373674f8d1d1d76f029b6
Author: Nico Pache <npache@redhat.com>

mm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio()

When a zone device folio is mapped as anonymous, folio_add_new_anon_rmap()
increments MTHP_STAT_NR_ANON. The corresponding decrement lives in
__free_pages_prepare() in page_alloc.c, but zone device folios are freed
via free_zone_device_folio() which never calls __free_pages_prepare().

> diff --git a/mm/memremap.c b/mm/memremap.c
> index 81766d8224009..accba23aef28c 100644
> --- a/mm/memremap.c
> +++ b/mm/memremap.c
> @@ -425,6 +425,7 @@ void free_zone_device_folio(struct folio *folio)
>  	if (WARN_ON_ONCE(!pgmap))
>  		return;
>  
>  	mem_cgroup_uncharge(folio);

[Severity: High]
This is a pre-existing issue, but can bypassing
folio_unqueue_deferred_split() here lead to list corruption on the deferred
split LRU or leak MTHP_STAT_NR_ANON_PARTIALLY_MAPPED?

ZONE_DEVICE folios bypass the normal cleanup path in __folio_put():

mm/swap.c:__folio_put() {
	if (unlikely(folio_is_zone_device(folio))) {
		free_zone_device_folio(folio);
		return;
	}
	...
}

If a ZONE_DEVICE folio (such as MEMORY_DEVICE_COHERENT) mapped as a large
anonymous folio is partially unmapped, folio_remove_rmap_pte() will queue
it on the deferred split list. When its refcount hits 0, it calls
free_zone_device_folio() directly.

When mem_cgroup_uncharge(folio) is called, if memcg is disabled or uncharged,
it returns early, leaving the freed folio linked in the deferred_split_lru.
When the deferred split shrinker runs under memory pressure, could this
iteration over freed memory cause a use-after-free crash? (If memcg is
enabled, the uncharge path forcefully unqueues it but emits a WARN_ON_ONCE).

Would explicitly calling folio_unqueue_deferred_split(folio) before
mem_cgroup_uncharge(folio) prevent this issue?

>  
>  	if (folio_test_anon(folio)) {
> +		mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, -1);
>  		for (i = 0; i < nr; i++)
>  			__ClearPageAnonExclusive(folio_page(folio, i));
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702172548.37075-1-npache@redhat.com?part=1