[PATCH v2] mm/huge_memory: Initialise workingset state before folio split

[PATCH v2] mm/huge_memory: Initialise workingset state before folio split

[Matt Fleming]

From: Matt Fleming <mfleming@cloudflare.com>

xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
__folio_split() leaves the xa_state's xa_lru unset. That lets a live,
memcg-charged xa_node exist without being linked into the mapping's
shadow_nodes list_lru; when reclaim later walks the list_lru it trips
VM_WARN_ON(!css_is_dying()).

Use mapping_set_update() to install both the workingset update callback
and the shadow_nodes list_lru on the xa_state.

Reported-by: syzbot+c5b060ce82921a2fd500@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c5b060ce82921a2fd500
Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()")
Cc: stable@vger.kernel.org
Reviewed-by: Zi Yan <ziy@nvidia.com>
Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
---
Changes in v2:
- Move mapping_set_update() after filemap_release_folio() succeeds.
- Add Zi Yan's Reviewed-by.

Link: https://lore.kernel.org/linux-mm/20260724195244.3715130-1-matt@readmodwrite.com/
---
 mm/huge_memory.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b5d1e9d4463d..4ddbc72e92fd 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4033,7 +4033,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 		gfp_t gfp;
 
 		mapping = folio->mapping;
-		min_order = mapping_min_folio_order(folio->mapping);
+		min_order = mapping_min_folio_order(mapping);
 		if (new_order < min_order) {
 			ret = -EINVAL;
 			goto out;
@@ -4047,6 +4047,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 			goto out;
 		}
 
+		mapping_set_update(&xas, mapping);
+
 		if (split_type == SPLIT_TYPE_UNIFORM) {
 			xas_set_order(&xas, folio->index, new_order);
 			xas_split_alloc(&xas, folio, old_order, gfp);
-- 
2.43.0

Re: [PATCH v2] mm/huge_memory: Initialise workingset state before folio split

[Andrew Morton]

On Sat, 25 Jul 2026 11:14:19 +0100 Matt Fleming <matt@readmodwrite.com> wrote:

> xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
> __folio_split() leaves the xa_state's xa_lru unset. That lets a live,
> memcg-charged xa_node exist without being linked into the mapping's
> shadow_nodes list_lru; when reclaim later walks the list_lru it trips
> VM_WARN_ON(!css_is_dying()).
> 
> Use mapping_set_update() to install both the workingset update callback
> and the shadow_nodes list_lru on the xa_state.

Thanks, I'll queue this as a hotfix.

Sashiko is wrong, methinks.  "Calling local_irq_disable() strictly
disables hardware interrupts" isn't true on PREEMPT_RT.

	https://sashiko.dev/#/patchset/20260725101419.3938406-1-matt@readmodwrite.com  

Re: [PATCH v2] mm/huge_memory: Initialise workingset state before folio split

[David Hildenbrand (Arm)]

On 7/25/26 12:14, Matt Fleming wrote:
> From: Matt Fleming <mfleming@cloudflare.com>
> 
> xas_try_split() adds __GFP_ACCOUNT for page-cache xa_nodes, but
> __folio_split() leaves the xa_state's xa_lru unset. That lets a live,
> memcg-charged xa_node exist without being linked into the mapping's
> shadow_nodes list_lru; when reclaim later walks the list_lru it trips
> VM_WARN_ON(!css_is_dying()).
> 
> Use mapping_set_update() to install both the workingset update callback
> and the shadow_nodes list_lru on the xa_state.
> 
> Reported-by: syzbot+c5b060ce82921a2fd500@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c5b060ce82921a2fd500
> Fixes: 58729c04cf10 ("mm/huge_memory: add buddy allocator like (non-uniform) folio_split()")
> Cc: stable@vger.kernel.org
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
> ---
> Changes in v2:
> - Move mapping_set_update() after filemap_release_folio() succeeds.
> - Add Zi Yan's Reviewed-by.
> 
> Link: https://lore.kernel.org/linux-mm/20260724195244.3715130-1-matt@readmodwrite.com/
> ---
>  mm/huge_memory.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index b5d1e9d4463d..4ddbc72e92fd 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -4033,7 +4033,7 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>  		gfp_t gfp;
>  
>  		mapping = folio->mapping;
> -		min_order = mapping_min_folio_order(folio->mapping);
> +		min_order = mapping_min_folio_order(mapping);
>  		if (new_order < min_order) {
>  			ret = -EINVAL;
>  			goto out;
> @@ -4047,6 +4047,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>  			goto out;
>  		}
>  
> +		mapping_set_update(&xas, mapping);
> +

It's entirely unclear when mapping_set_update() should/must be called. ... or
even what it does.

Why is it called "mapping_set_*" when, in fact, we modify the xas?

The more I look at it, the more angry it makes me :)

Can someone please try finding a better way to handle this?

E.g., can we somehow remember in the xarray that we have !dax_mapping(mapping)
&& !shmem_mapping(mapping) early, and just do the right thing from xas code? Or
is there some way we could have a mixture in the same xarray?


Anyhow, for this patch here, I guess it's fine. I am convinced nobody can say
that with confidence. Black magic.

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David