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;
Date:   Thu, 14 Jul 2022 17:27:28 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Dmitry Vyukov <dvyukov@google.com>
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>
Subject: Re: [syzbot] memory leak in xas_create
Message-ID: <YtBD8L4yIjKtIfw9@casper.infradead.org>
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>
 <CACT4Y+a=N3Q6f4dDcmONZYBHMgkO3MpbqoYDupo_N1tKJ=14Rg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+a=N3Q6f4dDcmONZYBHMgkO3MpbqoYDupo_N1tKJ=14Rg@mail.gmail.com>
Precedence: bulk

On Tue, Jul 12, 2022 at 03:29:29PM +0200, Dmitry Vyukov wrote:
> 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.

Oh, I meant to answer this.  The XArray does set bit 1 of the pointer
when it's stored in the tree.  However, this shouldn't affect kmemleak
(I would think) because it looks like a pointer to the third byte of the
allocation, so the allocation is still referenced, even if the first
byte of the allocation isn't referenced.

Also, I would expect kmemleak to report bugs all over if this were the
problem, because every node no matter how it's allocated gets its bit 1
set.