* kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] @ 2022-08-15 9:52 Max Schulze 2022-08-15 12:47 ` Will Deacon 0 siblings, 1 reply; 16+ messages in thread From: Max Schulze @ 2022-08-15 9:52 UTC (permalink / raw) To: linux-arm-kernel; +Cc: catalin.marinas, will, naush 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-15 9:52 kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] Max Schulze @ 2022-08-15 12:47 ` Will Deacon 2022-08-15 15:50 ` Marco Elver 0 siblings, 1 reply; 16+ messages in thread From: Will Deacon @ 2022-08-15 12:47 UTC (permalink / raw) To: Max Schulze Cc: linux-arm-kernel, catalin.marinas, naush, glider, elver, dvyukov, kasan-dev [+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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-15 12:47 ` Will Deacon @ 2022-08-15 15:50 ` Marco Elver 2022-08-16 10:52 ` Yee Lee (李建誼) 0 siblings, 1 reply; 16+ messages in thread From: Marco Elver @ 2022-08-15 15:50 UTC (permalink / raw) To: Will Deacon, Yee Lee Cc: Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-15 15:50 ` Marco Elver @ 2022-08-16 10:52 ` Yee Lee (李建誼) 2022-08-16 14:26 ` Will Deacon 0 siblings, 1 reply; 16+ messages in thread From: Yee Lee (李建誼) @ 2022-08-16 10:52 UTC (permalink / raw) To: Marco Elver, Will Deacon, akpm Cc: Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 10:52 ` Yee Lee (李建誼) @ 2022-08-16 14:26 ` Will Deacon 2022-08-16 14:34 ` Marco Elver 2022-08-16 23:39 ` Andrew Morton 0 siblings, 2 replies; 16+ messages in thread From: Will Deacon @ 2022-08-16 14:26 UTC (permalink / raw) To: Yee Lee (李建誼) Cc: Marco Elver, akpm, Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 14:26 ` Will Deacon @ 2022-08-16 14:34 ` Marco Elver 2022-08-16 15:31 ` Catalin Marinas 2022-08-16 23:39 ` Andrew Morton 1 sibling, 1 reply; 16+ messages in thread From: Marco Elver @ 2022-08-16 14:34 UTC (permalink / raw) To: Will Deacon Cc: Yee Lee (李建誼), akpm, Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 14:34 ` Marco Elver @ 2022-08-16 15:31 ` Catalin Marinas 2022-08-16 15:46 ` Marco Elver 0 siblings, 1 reply; 16+ messages in thread From: Catalin Marinas @ 2022-08-16 15:31 UTC (permalink / raw) To: Marco Elver Cc: Will Deacon, Yee Lee (李建誼), akpm, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 15:31 ` Catalin Marinas @ 2022-08-16 15:46 ` Marco Elver 2022-08-16 15:53 ` Catalin Marinas 0 siblings, 1 reply; 16+ messages in thread From: Marco Elver @ 2022-08-16 15:46 UTC (permalink / raw) To: Catalin Marinas Cc: Will Deacon, Yee Lee (李建誼), akpm, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 15:46 ` Marco Elver @ 2022-08-16 15:53 ` Catalin Marinas 0 siblings, 0 replies; 16+ messages in thread From: Catalin Marinas @ 2022-08-16 15:53 UTC (permalink / raw) To: Marco Elver Cc: Will Deacon, Yee Lee (李建誼), akpm, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 14:26 ` Will Deacon 2022-08-16 14:34 ` Marco Elver @ 2022-08-16 23:39 ` Andrew Morton 2022-08-17 6:25 ` Greg Kroah-Hartman 1 sibling, 1 reply; 16+ messages in thread From: Andrew Morton @ 2022-08-16 23:39 UTC (permalink / raw) To: Will Deacon Cc: Yee Lee, Marco Elver, Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev, Greg Kroah-Hartman 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-16 23:39 ` Andrew Morton @ 2022-08-17 6:25 ` Greg Kroah-Hartman 2022-08-17 8:23 ` Catalin Marinas 0 siblings, 1 reply; 16+ messages in thread From: Greg Kroah-Hartman @ 2022-08-17 6:25 UTC (permalink / raw) To: Andrew Morton Cc: Will Deacon, Yee Lee, Marco Elver, Max Schulze, linux-arm-kernel, catalin.marinas, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-17 6:25 ` Greg Kroah-Hartman @ 2022-08-17 8:23 ` Catalin Marinas 2022-08-17 15:01 ` Marco Elver 0 siblings, 1 reply; 16+ messages in thread From: Catalin Marinas @ 2022-08-17 8:23 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Andrew Morton, Will Deacon, Yee Lee, Marco Elver, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-17 8:23 ` Catalin Marinas @ 2022-08-17 15:01 ` Marco Elver 2022-08-17 16:52 ` Greg Kroah-Hartman 0 siblings, 1 reply; 16+ messages in thread From: Marco Elver @ 2022-08-17 15:01 UTC (permalink / raw) To: Catalin Marinas Cc: Greg Kroah-Hartman, Andrew Morton, Will Deacon, Yee Lee, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-17 15:01 ` Marco Elver @ 2022-08-17 16:52 ` Greg Kroah-Hartman 2022-08-17 17:02 ` Catalin Marinas 0 siblings, 1 reply; 16+ messages in thread From: Greg Kroah-Hartman @ 2022-08-17 16:52 UTC (permalink / raw) To: Marco Elver Cc: Catalin Marinas, Andrew Morton, Will Deacon, Yee Lee, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-17 16:52 ` Greg Kroah-Hartman @ 2022-08-17 17:02 ` Catalin Marinas 2022-08-17 17:23 ` Greg Kroah-Hartman 0 siblings, 1 reply; 16+ messages in thread From: Catalin Marinas @ 2022-08-17 17:02 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Marco Elver, Andrew Morton, Will Deacon, Yee Lee, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] 2022-08-17 17:02 ` Catalin Marinas @ 2022-08-17 17:23 ` Greg Kroah-Hartman 0 siblings, 0 replies; 16+ messages in thread From: Greg Kroah-Hartman @ 2022-08-17 17:23 UTC (permalink / raw) To: Catalin Marinas Cc: Marco Elver, Andrew Morton, Will Deacon, Yee Lee, Max Schulze, linux-arm-kernel, naush, glider, dvyukov, kasan-dev 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-08-17 17:24 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-08-15 9:52 kmemleak: Cannot insert 0xffffff806e24f000 into the object search tree (overlaps existing) [RPi CM4] Max Schulze 2022-08-15 12:47 ` Will Deacon 2022-08-15 15:50 ` Marco Elver 2022-08-16 10:52 ` Yee Lee (李建誼) 2022-08-16 14:26 ` Will Deacon 2022-08-16 14:34 ` Marco Elver 2022-08-16 15:31 ` Catalin Marinas 2022-08-16 15:46 ` Marco Elver 2022-08-16 15:53 ` Catalin Marinas 2022-08-16 23:39 ` Andrew Morton 2022-08-17 6:25 ` Greg Kroah-Hartman 2022-08-17 8:23 ` Catalin Marinas 2022-08-17 15:01 ` Marco Elver 2022-08-17 16:52 ` Greg Kroah-Hartman 2022-08-17 17:02 ` Catalin Marinas 2022-08-17 17:23 ` Greg Kroah-Hartman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.