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

[ZhengYuan Huang <gality369@gmail.com>]

On Sun, Apr 19, 2026 at 10:21 PM Lorenzo Stoakes <ljs@kernel.org> wrote:
>
> On Sun, Apr 19, 2026 at 10:19:59AM +0200, David Hildenbrand (Arm) wrote:
> > 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.
>
> Let me take more of a look then!
>
> >
> > 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.
>
> Ahhh, no not that one (it affects merge of VMAs that have a CoW hierarchy which
> we shouldn't allow) but 61f67c230a5e actually could cause this.
>
> Can see from https://kernel.dance/#61f67c230a5e it was backported to 6.18.7 I
> think.
>
> ZhengYuan - can you try seeing if it repro's with/without that?
>
> If you're testing literally at v6.18 in Linus's tree say and NOT on a stable
> tree, then that's your problem - you're essentially testing a known-buggy kernel
> (we always find stuff later and send to stable, just how it is).

I can reproduce the issue on 6.18.7, but I can no longer reproduce it on 6.18.8.
So it does look like the problem has already been fixed by commit 61f67c230a5e.

Thanks everyone for the insights and pointers.

This issue was originally found by our fuzzing tool. Unfortunately,
our reproducer generation is still a bit unreliable, so I cannot
provide a standalone reproducer at the moment. However, given that the
issue appears to be fixed, I suppose that is no longer strictly
necessary.

Let me know if further testing is needed.

Thanks,
ZhengYuan Huang