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

[Will Deacon]

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?

Will