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

[Lorenzo Stoakes]

On Wed, Apr 22, 2026 at 03:59:57PM +0800, ZhengYuan Huang wrote:
> On Sun, Apr 19, 2026 at 10:21 PM Lorenzo Stoakes <ljs@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > 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.

Pointers always makes me think of https://xkcd.com/138/ ;)

Thanks for reporting the issue, I'm glad that the fix has that handled (mea
culpa for introducing the bug! :)

>
> 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.

No that's fine, you've confirmed the expected revisions and really I think it
has to be that fix that got it.

>
> Thanks,
> ZhengYuan Huang

Cheers, Lorenzo