Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <000000000000eb2d6c05e35a0d73@google.com> <20220711133808.d86400ce9960febcb0fd537b@linux-foundation.org>
 <YsyMQ2jzOICVbCda@casper.infradead.org> <CACT4Y+bL3aM-cVeYSLU7az1x2Yj1vH7GaQSq=Z-BGc5Vk1Vi4w@mail.gmail.com>
 <Ys1r06szkVi3QEai@casper.infradead.org> <CACT4Y+Z44fS04StzMh+sfUWo-k5sjYf3VGhhK2ppkHP=9RZQEw@mail.gmail.com>
 <Ys1v1548IkSJ45F/@casper.infradead.org>
In-Reply-To: <Ys1v1548IkSJ45F/@casper.infradead.org>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Tue, 12 Jul 2022 15:29:29 +0200
Message-ID: <CACT4Y+a=N3Q6f4dDcmONZYBHMgkO3MpbqoYDupo_N1tKJ=14Rg@mail.gmail.com>
Subject: Re: [syzbot] memory leak in xas_create
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        syzkaller-bugs@googlegroups.com,
        "Zach O'Keefe" <zokeefe@google.com>,
        Yang Shi <shy828301@gmail.com>,
        Liam Howlett <liam.howlett@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 12 Jul 2022 at 14:58, Matthew Wilcox <willy@infradead.org> wrote:
> > > > > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > syzbot found the following issue on:
> > > > > > >
> > > > > > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > > > > > git tree:       upstream
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > > > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > > > > > >
> > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > > > > > >
> > > > > > > 2022/07/05 05:22:17 executed programs: 828
> > > > > > > 2022/07/05 05:22:23 executed programs: 846
> > > > > > > 2022/07/05 05:22:30 executed programs: 866
> > > > > > > 2022/07/05 05:22:37 executed programs: 875
> > > > > > > BUG: memory leak
> > > > > >
> > > > > > Thanks.  Presumably due to khugepaged changes.
> > > > >
> > > > > Huh, I was expecting it to be something I'd messed up.  I've been
> > > > > looking at it today, but no luck figuring it out so far.
> > > > >
> > > > > > Can we expect a bisection search?
> > > > >
> > > > > We only have a syz reproducer so far, and if I understand correctly,
> > > > > it's probably because this is a flaky test (because it's trying to
> > > > > find something that's a race condition).
> > > > >
> > > > > I expect a bisection search to go badly wrong if this is true.
> > > >
> > > > Is it possible that parts of xas are not freed on the error paths?
> > > > I don't immediately see where anything is freed on these error paths:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675
> > >
> > > There's nothing to free; if a node is allocated, then it's stored in
> > > the tree where it can later be found and reused.
> >
> > What I was thinking of is:
> >
> > The leaked memory is allocated with:
> > xas_create_range(&xas);
> > here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670
> >
> > So I assumed the nodes stored in the xas object, which is local to the
> > collapse_file() function.
>
> Yes, that's a reasonable thing to think, but it's actually not how
> it works.  When we allocate a node in xas_create(), we put it straight
> into the tree without storing it in xas->xa_alloc.  We may then end
> up not using it, but the node isn't leaked because it's in the tree.
>
> If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
> we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
> it in xas->xa_alloc; then we go round the loop again where xas_create()
> will take the node from xas->xa_alloc.  But the backtraces here don't
> implicate xas_nomem().

I see. Thanks for the explanation.

Then I think it's still possible that this is a KMEMLEAK false
positive. IIRC it may have some false positives since it does not do
full stop-the-world before scanning memory/registers. syzkaller tries
to circumvent this by doing multiple scans with some delays, but it
does not give 100% guarantee.
And I am assuming this code does not try to hide pointers by storing
something in low/high bits, etc.


> > So if we do "goto out" here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676
> >
> > There does not seem to be anything that frees anything stored in the xas:
> >
> > out:
> >     VM_BUG_ON(!list_empty(&pagelist));
> >     if (!IS_ERR_OR_NULL(*hpage))
> >         mem_cgroup_uncharge(page_folio(*hpage));
> >     /* TODO: tracepoints */
> > }
> >