Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4]

From: Catalin Marinas <catalin.marinas@arm.com>
To: Marco Elver <elver@google.com>
Cc: "Will Deacon" <will@kernel.org>,
	"Yee Lee (李建誼)" <Yee.Lee@mediatek.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Max Schulze" <max.schulze@online.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"naush@raspberrypi.com" <naush@raspberrypi.com>,
	"glider@google.com" <glider@google.com>,
	"dvyukov@google.com" <dvyukov@google.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Subject: Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4]
Date: Tue, 16 Aug 2022 16:31:56 +0100	[thread overview]
Message-ID: <Yvu4bBmykYr+0CXk@arm.com> (raw)
In-Reply-To: <CANpmjNMd=ODXkx37wqYNFhivf_oH-FSo+O4RDKn3wV14kCe69g@mail.gmail.com>

On Tue, Aug 16, 2022 at 04:34:31PM +0200, Marco Elver wrote:
> On Tue, 16 Aug 2022 at 16:26, Will Deacon <will@kernel.org> wrote:
> > On Tue, Aug 16, 2022 at 10:52:19AM +0000, Yee Lee (李建誼) wrote:
> > > The kfence patch(07313a2b29ed) is based on the prior changes in
> > > kmemleak(0c24e061196c2 , merged in v6.0-rc1), but it shows up earlier in
> > > v5.19.
> > >
> > > @akpm
> > > Andrew, sorry that the short fix tag caused confusing. Can we pull out the
> > > patch(07313a2b29e) in v5.19.x?
> > >
> > > Kfence: (07313a2b29ed) https://github.com/torvalds/linux/commit/07313a2b29ed1079eaa7722624544b97b3ead84b
> > > Kmemleak: (0c24e061196c2) https://github.com/torvalds/linux/commit/0c24e061196c21d53328d60f4ad0e5a2b3183343
> >
> > Hmm, so if I'm understanding correctly then:
> >
> >  - The kfence fix (07313a2b29ed) depends on a kmemleak change (0c24e061196c2)
> >    but the patches apply cleanly on their own.
> >
> >  - The kmemleak change landed in the v6.0 merge window, but the kfence fix
> >    landed in 5.19 (and has a fixes tag)
> >
> > So it sounds like we can either:
> >
> >  1. Revert 07313a2b29ed in the stable trees which contain it and then fix
> >     the original issue some other way.
> >
> > or,
> >
> >  2. Backport 0c24e061196c2 everywhere that has 07313a2b29ed. Judging solely
> >     by the size of the patch, this doesn't look like a great idea.
> >
> > Is that right?

That's right. Either option should work but I think with (2) there may
be a few more commits to be added.

> Right, looks like the kfence fix didn't need to be in 5.19. In any
> case, this patch I just sent:
> 
> https://lore.kernel.org/all/20220816142529.1919543-1-elver@google.com/
> 
> fixes the issue for 5.19 as well, because memblock has always used
> kmemleak's kmemleak_*_phys() API and technically we should free it
> through phys as well.
> 
> As far as I can tell, that's also the right thing to do in 6.0-rc1
> with 0c24e061196c2, because we have the slab post-alloc hooks that
> want to register kfence objects via kmemleak. Unless of course somehow
> both "ignore" and "free" works, but "ignore" just sounds wrong in this
> case. Any thoughts?

Since commit 0c24e061196c2, kmemleak has different namespaces for the
virtual and physical addresses and there is no risk of overlap. So the
comment in your proposed fix can be confusing in 6.0-rc1 (but fine in
5.19).

In general, if an object is allocated and never freed,
kmemleak_ignore*() is more appropriate, so I'm more inclined to only
send your kmemleak_free_part_phys() fix to 5.19.x rather than mainline.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel