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

[Marco Elver]

On Tue, 16 Aug 2022 at 16:26, Will Deacon <will at 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?

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?

Thanks,
-- Marco