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

[Andrew Morton]

On Tue, 16 Aug 2022 15:26:29 +0100 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.

07313a2b29ed should not be in the stable tree.  It did not have a
cc:stable and we've asked the stable tree maintainers not to blindly
backport everything that has a Fixes: tag.

How did this happen?

> 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?
> 
> Will