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

["David Hildenbrand (Arm)" <david@kernel.org>]

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