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

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

[Max Schulze]

Hello,

I get these messages when booting 5.19.0 on RaspberryPi CM4.

Full boot log is at https://pastebin.ubuntu.com/p/mVhgBwxqPj/

Anyone seen this? What can I do ?

Thanks,

Max


[0.087630] kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
[0.087756] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-v8-0815+ #5
[0.087836] Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
[0.087901] Call trace:
[0.087941]  dump_backtrace.part.0+0x1dc/0x1ec
[0.088029]  show_stack+0x24/0x80
[0.088089]  dump_stack_lvl+0x8c/0xb8
[0.088161]  dump_stack+0x1c/0x38
[0.088224]  create_object.isra.0+0x490/0x4b0
[0.088298]  kmemleak_alloc+0x3c/0x50
[0.088365]  kmem_cache_alloc+0x2f8/0x450
[0.088435]  __proc_create+0x18c/0x400
[0.088509]  proc_create_reg+0x54/0xd0
[0.088569]  proc_create_seq_private+0x94/0x120
[0.088634]  init_mm_internals+0x1d8/0x248
[0.088704]  kernel_init_freeable+0x188/0x388
[0.088776]  kernel_init+0x30/0x150
[0.088837]  ret_from_fork+0x10/0x20
[0.088903] kmemleak: Kernel memory leak detector disabled
[0.088958] kmemleak: Object 0xffffff806e24d000 (size 2097152):
[0.089021] kmemleak:   comm "swapper", pid 0, jiffies 4294892296
[0.089085] kmemleak:   min_count = -1
[0.089131] kmemleak:   count = 0
[0.089174] kmemleak:   flags = 0x5
[0.089219] kmemleak:   checksum = 0
[0.089264] kmemleak:   backtrace:
[0.089306]  kmemleak_alloc_phys+0x94/0xb0
[0.089379]  memblock_alloc_range_nid+0x1c0/0x20c
[0.089460]  memblock_alloc_internal+0x88/0x100
[0.089532]  memblock_alloc_try_nid+0x148/0x1ac
[0.089604]  kfence_alloc_pool+0x44/0x6c
[0.089674]  mm_init+0x28/0x98
[0.089733]  start_kernel+0x178/0x3e8
[0.089797]  __primary_switched+0xc4/0xcc
[0.090185] cblist_init_generic: Setting adjustable number of callback queues.


early_memtest reports no problems, 


[0.000000] Zone ranges:
[0.000000]   DMA  [mem 0x0000000000000000-0x000000003fffffff]
[0.000000]   DMA32[mem 0x0000000040000000-0x000000007fffffff]
[0.000000]   Normal   empty
[0.000000] Movable zone start for each node
[0.000000] Early memory node ranges
[0.000000]   node   0: [mem 0x0000000000000000-0x0000000037ffffff]
[0.000000]   node   0: [mem 0x0000000040000000-0x000000007fffffff]
[0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]


The Address differs a bit across reboots, but callstack looks always the same, and "Object is always 0xffffff806e24d000 (size 2097152)" 


Aug 15 03:42:44 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 03:50:37 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 03:50:37 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 06:58:14 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 07:04:01 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 07:04:01 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 07:27:40 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 07:36:10 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 07:41:57 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 07:47:43 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 07:53:29 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 07:59:18 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:05:06 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:13:00 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:21:47 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:27:36 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:33:23 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 08:39:13 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:45:03 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 08:50:51 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 08:56:40 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 09:02:27 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 09:08:16 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 09:23:45 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 09:32:34 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 09:38:23 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 09:44:09 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 09:49:55 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 09:55:40 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 10:01:27 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 10:07:19 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 10:15:13 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 10:24:00 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 10:28:56 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 10:34:44 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 10:42:45 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 10:51:32 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
Aug 15 11:03:53 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
Aug 15 11:14:55 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)

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

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

[Will Deacon]

[+kfence folks as kfence_alloc_pool() is starting the stacktrace]

On Mon, Aug 15, 2022 at 11:52:05AM +0200, Max Schulze wrote:
> Hello,
> 
> I get these messages when booting 5.19.0 on RaspberryPi CM4.
> 
> Full boot log is at https://pastebin.ubuntu.com/p/mVhgBwxqPj/
> 
> Anyone seen this? What can I do ?
> 
> Thanks,
> 
> Max
> 
> 
> [0.087630] kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> [0.087756] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-v8-0815+ #5
> [0.087836] Hardware name: Raspberry Pi Compute Module 4 Rev 1.0 (DT)
> [0.087901] Call trace:
> [0.087941]  dump_backtrace.part.0+0x1dc/0x1ec
> [0.088029]  show_stack+0x24/0x80
> [0.088089]  dump_stack_lvl+0x8c/0xb8
> [0.088161]  dump_stack+0x1c/0x38
> [0.088224]  create_object.isra.0+0x490/0x4b0
> [0.088298]  kmemleak_alloc+0x3c/0x50
> [0.088365]  kmem_cache_alloc+0x2f8/0x450
> [0.088435]  __proc_create+0x18c/0x400
> [0.088509]  proc_create_reg+0x54/0xd0
> [0.088569]  proc_create_seq_private+0x94/0x120
> [0.088634]  init_mm_internals+0x1d8/0x248
> [0.088704]  kernel_init_freeable+0x188/0x388
> [0.088776]  kernel_init+0x30/0x150
> [0.088837]  ret_from_fork+0x10/0x20
> [0.088903] kmemleak: Kernel memory leak detector disabled
> [0.088958] kmemleak: Object 0xffffff806e24d000 (size 2097152):
> [0.089021] kmemleak:   comm "swapper", pid 0, jiffies 4294892296
> [0.089085] kmemleak:   min_count = -1
> [0.089131] kmemleak:   count = 0
> [0.089174] kmemleak:   flags = 0x5
> [0.089219] kmemleak:   checksum = 0
> [0.089264] kmemleak:   backtrace:
> [0.089306]  kmemleak_alloc_phys+0x94/0xb0
> [0.089379]  memblock_alloc_range_nid+0x1c0/0x20c
> [0.089460]  memblock_alloc_internal+0x88/0x100
> [0.089532]  memblock_alloc_try_nid+0x148/0x1ac
> [0.089604]  kfence_alloc_pool+0x44/0x6c
> [0.089674]  mm_init+0x28/0x98
> [0.089733]  start_kernel+0x178/0x3e8
> [0.089797]  __primary_switched+0xc4/0xcc
> [0.090185] cblist_init_generic: Setting adjustable number of callback queues.
> 
> 
> early_memtest reports no problems, 
> 
> 
> [0.000000] Zone ranges:
> [0.000000]   DMA  [mem 0x0000000000000000-0x000000003fffffff]
> [0.000000]   DMA32[mem 0x0000000040000000-0x000000007fffffff]
> [0.000000]   Normal   empty
> [0.000000] Movable zone start for each node
> [0.000000] Early memory node ranges
> [0.000000]   node   0: [mem 0x0000000000000000-0x0000000037ffffff]
> [0.000000]   node   0: [mem 0x0000000040000000-0x000000007fffffff]
> [0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]
> 
> 
> The Address differs a bit across reboots, but callstack looks always the same, and "Object is always 0xffffff806e24d000 (size 2097152)" 
> 
> 
> Aug 15 03:42:44 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 03:50:37 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 03:50:37 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 06:58:14 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 07:04:01 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 07:04:01 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 07:27:40 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 07:36:10 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 07:41:57 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 07:47:43 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 07:53:29 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 07:59:18 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:05:06 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:13:00 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:21:47 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:27:36 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:33:23 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 08:39:13 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:45:03 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 08:50:51 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 08:56:40 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 09:02:27 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 09:08:16 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 09:23:45 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 09:32:34 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 09:38:23 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 09:44:09 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 09:49:55 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 09:55:40 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 10:01:27 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 10:07:19 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 10:15:13 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 10:24:00 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 10:28:56 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 10:34:44 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 10:42:45 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 10:51:32 kernel:kmemleak: Cannot insert 0xffffff806e24ff40 into the object search tree (overlaps existing)
> Aug 15 11:03:53 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)
> Aug 15 11:14:55 kernel:kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing)

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

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

[Marco Elver]

On Mon, 15 Aug 2022 at 14:47, Will Deacon <will@kernel.org> wrote:
>
> [+kfence folks as kfence_alloc_pool() is starting the stacktrace]
>
> On Mon, Aug 15, 2022 at 11:52:05AM +0200, Max Schulze wrote:
> > Hello,
> >
> > I get these messages when booting 5.19.0 on RaspberryPi CM4.
> >
> > Full boot log is at https://pastebin.ubuntu.com/p/mVhgBwxqPj/
> >
> > Anyone seen this? What can I do ?

I think the kmemleak_ignore_phys() in [1] is wrong. It probably wants
to be a kmemleak_free_part_phys().

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/kfence?h=v5.19&id=07313a2b29ed1079eaa7722624544b97b3ead84b

+Cc Yee

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

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

[Yee Lee (李建誼)]

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


The overlapping happened as kfence pool occupied the virtual address which supposed to be available for later object allocations. With the changes in kmemleak, the pool won't be recorded in VA.

The pool's kmemleak object is created from memblock_alloc and can be freed as calling memblock_free. 
If there is no more operating on its PA, we can just ignore it not removing it.


Best Regards,
Yee

-----Original Message-----
From: Marco Elver <elver@google.com> 
Sent: Monday, August 15, 2022 11:50 PM
To: Will Deacon <will@kernel.org>; Yee Lee (李建誼) <Yee.Lee@mediatek.com>
Cc: Max Schulze <max.schulze@online.de>; linux-arm-kernel@lists.infradead.org; catalin.marinas@arm.com; naush@raspberrypi.com; glider@google.com; dvyukov@google.com; kasan-dev@googlegroups.com
Subject: Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4]

On Mon, 15 Aug 2022 at 14:47, Will Deacon <will@kernel.org> wrote:
>
> [+kfence folks as kfence_alloc_pool() is starting the stacktrace]
>
> On Mon, Aug 15, 2022 at 11:52:05AM +0200, Max Schulze wrote:
> > Hello,
> >
> > I get these messages when booting 5.19.0 on RaspberryPi CM4.
> >
> > Full boot log is at 
> > https://urldefense.com/v3/__https://pastebin.ubuntu.com/p/mVhgBwxqPj
> > /__;!!CTRNKA9wMg0ARbw!zoc_1ye57MyrB-45TNoz5wwiQLHWrXAblWZLGm1RPhPaTX
> > 6WWyI6wxHFOOrUwzw$
> >
> > Anyone seen this? What can I do ?

I think the kmemleak_ignore_phys() in [1] is wrong. It probably wants to be a kmemleak_free_part_phys().

[1] https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/kfence?h=v5.19&id=07313a2b29ed1079eaa7722624544b97b3ead84b__;!!CTRNKA9wMg0ARbw!zoc_1ye57MyrB-45TNoz5wwiQLHWrXAblWZLGm1RPhPaTX6WWyI6wxHFQ-Ttpzo$ 

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

Re: 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

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

Re: 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@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

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

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

[Catalin Marinas]

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

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

[Marco Elver]

On Tue, 16 Aug 2022 at 17:32, Catalin Marinas <catalin.marinas@arm.com> wrote:
[...]
> > 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).

Makes sense.

> 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.

So it sounds like we should just ask stable to revert 07313a2b29ed
then, if the patch switching to kmemleak_free_part_phys() should not
go to 6.0. Is that the most reasonable option? If so, I'll go ahead
and send stable the email to do so.

Thanks,
-- Marco

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

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

[Catalin Marinas]

On Tue, Aug 16, 2022 at 05:46:43PM +0200, Marco Elver wrote:
> On Tue, 16 Aug 2022 at 17:32, Catalin Marinas <catalin.marinas@arm.com> wrote:
> [...]
> > > 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?
[...]
> > 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.
> 
> So it sounds like we should just ask stable to revert 07313a2b29ed
> then, if the patch switching to kmemleak_free_part_phys() should not
> go to 6.0. Is that the most reasonable option? If so, I'll go ahead
> and send stable the email to do so.

Yes, I think the revert is probably better.

-- 
Catalin

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

Re: 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@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

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

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

[Greg Kroah-Hartman]

On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> On Tue, 16 Aug 2022 15:26:29 +0100 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.
> 
> 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?

I do not see 07313a2b29ed in any stable tree or release that I can
find, am I missing something?

thanks,

greg k-h

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

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

[Catalin Marinas]

On Wed, Aug 17, 2022 at 08:25:06AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> > On Tue, 16 Aug 2022 15:26:29 +0100 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.
> > 
> > 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?
> 
> I do not see 07313a2b29ed in any stable tree or release that I can
> find, am I missing something?

I think commit 07313a2b29ed went in mainline 5.19, see this merge:
39c3c396f813 ("Merge tag 'mm-hotfixes-stable-2022-07-26' of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). So there was no
stable involvement.

-- 
Catalin

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

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

[Marco Elver]

On Wed, 17 Aug 2022 at 10:23, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Aug 17, 2022 at 08:25:06AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> > > On Tue, 16 Aug 2022 15:26:29 +0100 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.
> > >
> > > 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?
> >
> > I do not see 07313a2b29ed in any stable tree or release that I can
> > find, am I missing something?
>
> I think commit 07313a2b29ed went in mainline 5.19, see this merge:
> 39c3c396f813 ("Merge tag 'mm-hotfixes-stable-2022-07-26' of
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). So there was no
> stable involvement.

I sent the revert as a PATCH for 5.19.y here:
https://lore.kernel.org/all/20220816163641.2359996-1-elver@google.com/

Thanks,
-- Marco

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

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

[Greg Kroah-Hartman]

On Wed, Aug 17, 2022 at 05:01:50PM +0200, Marco Elver wrote:
> On Wed, 17 Aug 2022 at 10:23, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > On Wed, Aug 17, 2022 at 08:25:06AM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> > > > On Tue, 16 Aug 2022 15:26:29 +0100 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.
> > > >
> > > > 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?
> > >
> > > I do not see 07313a2b29ed in any stable tree or release that I can
> > > find, am I missing something?
> >
> > I think commit 07313a2b29ed went in mainline 5.19, see this merge:
> > 39c3c396f813 ("Merge tag 'mm-hotfixes-stable-2022-07-26' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). So there was no
> > stable involvement.
> 
> I sent the revert as a PATCH for 5.19.y here:
> https://lore.kernel.org/all/20220816163641.2359996-1-elver@google.com/

Why do we need a revert here but not one for Linus's tree?

confused,

greg k-h

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

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

[Catalin Marinas]

On Wed, Aug 17, 2022 at 06:52:35PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 17, 2022 at 05:01:50PM +0200, Marco Elver wrote:
> > On Wed, 17 Aug 2022 at 10:23, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > On Wed, Aug 17, 2022 at 08:25:06AM +0200, Greg Kroah-Hartman wrote:
> > > > On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> > > > > On Tue, 16 Aug 2022 15:26:29 +0100 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.
> > > > >
> > > > > 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?
> > > >
> > > > I do not see 07313a2b29ed in any stable tree or release that I can
> > > > find, am I missing something?
> > >
> > > I think commit 07313a2b29ed went in mainline 5.19, see this merge:
> > > 39c3c396f813 ("Merge tag 'mm-hotfixes-stable-2022-07-26' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). So there was no
> > > stable involvement.
> > 
> > I sent the revert as a PATCH for 5.19.y here:
> > https://lore.kernel.org/all/20220816163641.2359996-1-elver@google.com/
> 
> Why do we need a revert here but not one for Linus's tree?

This commit was meant as a fix for 0c24e061196c21d5 ("mm: kmemleak: add
rbtree and store physical address for objects allocated with PA") which
only made it into 6.0-rc1. But it ended up in 5.19 without the commit it
was fixing.

-- 
Catalin

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

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

[Greg Kroah-Hartman]

On Wed, Aug 17, 2022 at 06:02:47PM +0100, Catalin Marinas wrote:
> On Wed, Aug 17, 2022 at 06:52:35PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 17, 2022 at 05:01:50PM +0200, Marco Elver wrote:
> > > On Wed, 17 Aug 2022 at 10:23, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > > On Wed, Aug 17, 2022 at 08:25:06AM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, Aug 16, 2022 at 04:39:43PM -0700, Andrew Morton wrote:
> > > > > > On Tue, 16 Aug 2022 15:26:29 +0100 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.
> > > > > >
> > > > > > 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?
> > > > >
> > > > > I do not see 07313a2b29ed in any stable tree or release that I can
> > > > > find, am I missing something?
> > > >
> > > > I think commit 07313a2b29ed went in mainline 5.19, see this merge:
> > > > 39c3c396f813 ("Merge tag 'mm-hotfixes-stable-2022-07-26' of
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm"). So there was no
> > > > stable involvement.
> > > 
> > > I sent the revert as a PATCH for 5.19.y here:
> > > https://lore.kernel.org/all/20220816163641.2359996-1-elver@google.com/
> > 
> > Why do we need a revert here but not one for Linus's tree?
> 
> This commit was meant as a fix for 0c24e061196c21d5 ("mm: kmemleak: add
> rbtree and store physical address for objects allocated with PA") which
> only made it into 6.0-rc1. But it ended up in 5.19 without the commit it
> was fixing.

Ah, that's why the Fixes: tag was referencing a commit in the "future".

{sigh}

I'll go queue this up now, thanks.

greg k-h

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