Re: [PATCH] mm: prepare anon_vma before swapin rmap

David Hildenbrand (Arm)
2026-04-19T08:20:08Z

On 4/18/26 11:35, Lorenzo Stoakes wrote:
> On Fri, Apr 17, 2026 at 01:57:59PM +0200, David Hildenbrand (Arm) wrote:
>> Maybe there was a scenario where we could have lost vma->anon_vma during
>> a merge, resulting in a swapped page in an anon_vma.
>
> Unless there's a bug (and correct me if I'm misinterpreting), VMA merge requires
> vma->anon_vma to either be equal for merged adjacent VMAs, or one or the other
> VMA to have NULL vma->anon_vma, in which case we set vma->anon_vma in the merged
> VMA.

I think you didn't understand what I was trying to say.

The reporter claimed that it happened on 6.18. Nobody knows on which
patch version (stable tree?).

I was wondering whether your fix

commit 3b617fd3d317bf9dd7e2c233e56eafef05734c9d
Author: Lorenzo Stoakes <ljs@kernel.org>
Date: Mon Jan 5 20:11:49 2026 +0000

mm/vma: enforce VMA fork limit on unfaulted,faulted mremap merge too

that went into 6.19 might have resolved this problem.

Your fix stated "allow an unfaulted/faulted merge with a VMA that has
been forked", so I was wondering whether that could have resulted in a
situation with anon folios without vma->anon_vma (losing vma->anon_vma
during the merge).

But I am not sure if 879bca0a2c4f could have triggered that. Are you
aware of other fixes that went into 6.19 that could have fixed such a
scenario?

--
Cheers,

David