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

[Matthew Wilcox <willy@infradead.org>]

On Fri, Apr 17, 2026 at 03:36:59PM +0200, Vlastimil Babka (SUSE) wrote:
> On 4/17/26 15:03, Matthew Wilcox wrote:
> > On Fri, Apr 17, 2026 at 01:57:59PM +0200, David Hildenbrand (Arm) wrote:
> >> Just speculating, we had
> >> 
> >> 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
> >> 
> >> Go into v6.19.
> >> 
> >> 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.
> >> 
> >> If this cannot be reproduced on 6.19+,there is nothing to worry about.
> > 
> > ... except that 6.18 is LTS so we need a fix for that kernel version.
> 
> It's there: https://kernel.dance/#3b617fd3d317bf9dd7e2c233e56eafef05734c9d
> 
> > And maybe 6.12 as well (a373baed5a9d went into 6.9, so no need to
> > go further back than that)
> 
> Not there (yet?) but it was tagged stable.

879bca0a2c4f (the commit fixed by 3b617fd3d317) went into 6.15, so if
that's the problem then there's no need to backport 3b617fd3d317 to 6.12.
Unless someone backported 879bca0a2c4f to 6.12 which they might have
since it was a fix for a 2011 commit.  But so far nobody seems to have
done that, and since it's only a performance bug (right?), probably
nobody will bother.