* Re: [PATCH] lockdep: Fix static memory detection even more [not found] ` <b7526bf6-886f-457a-beba-84ae9f75bc77@roeck-us.net> @ 2023-09-03 21:11 ` Helge Deller 2023-09-03 23:08 ` Guenter Roeck 0 siblings, 1 reply; 4+ messages in thread From: Helge Deller @ 2023-09-03 21:11 UTC (permalink / raw) To: Guenter Roeck, Linus Torvalds, linux-kernel, linux-fbdev, dri-devel Cc: Andrew Morton, Greg Kroah-Hartman, Rafael J. Wysocki, linux-parisc, Borislav Petkov, Peter Zijlstra * Guenter Roeck <linux@roeck-us.net>: > Hi, > > On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote: > > On the parisc architecture, lockdep reports for all static objects which > > are in the __initdata section (e.g. "setup_done" in devtmpfs, > > "kthreadd_done" in init/main.c) this warning: > > > > INFO: trying to register non-static key. > > > > The warning itself is wrong, because those objects are in the __initdata > > section, but the section itself is on parisc outside of range from > > _stext to _end, which is why the static_obj() functions returns a wrong > > answer. > > > > While fixing this issue, I noticed that the whole existing check can > > be simplified a lot. > > Instead of checking against the _stext and _end symbols (which include > > code areas too) just check for the .data and .bss segments (since we check a > > data object). This can be done with the existing is_kernel_core_data() > > macro. > > > > In addition objects in the __initdata section can be checked with > > init_section_contains(). > > > > This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static > > memory detection"). > > > > Tested on x86-64 and parisc. > > > > Signed-off-by: Helge Deller <deller@gmx.de> > > Fixes: bac59d18c701 ("x86/setup: Fix static memory detection") > > On loongarch, this patch results in the following backtrace. > > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > EFI stub: Exiting boot services > [ 0.000000] INFO: trying to register non-static key. > [ 0.000000] The code is fine but needs lockdep annotation, or maybe > [ 0.000000] you didn't initialize this object before use? > [ 0.000000] turning off the locking correctness validator. > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #1 > [ 0.000000] Stack : 0000000000000000 0000000000000000 9000000000223d6c 9000000001df0000 > [ 0.000000] 9000000001df39a0 9000000001df39a8 0000000000000000 0000000000000000 > [ 0.000000] 9000000001df39a8 0000000000000001 0000000000000000 900000000154b910 > [ 0.000000] fffffffffffffffe 9000000001df39a8 0000000000000000 0000000000000000 > [ 0.000000] 0000000000000001 0000000000000003 0000000000000010 0000000000000030 > [ 0.000000] 0000000000000063 0000000000000001 0000000000000000 0000000000000000 > [ 0.000000] 0000000000000000 0000000000000000 9000000001c60650 9000000001e12000 > [ 0.000000] 0000000000000000 9000000001560bc0 0000000000000000 9000000002ee6000 > [ 0.000000] 0000000000000000 0000000000000000 9000000000223d84 0000000000000000 > [ 0.000000] 00000000000000b0 0000000000000004 0000000000000000 0000000000000800 > [ 0.000000] ... > [ 0.000000] Call Trace: > [ 0.000000] [<9000000000223d84>] show_stack+0x5c/0x180 > [ 0.000000] [<900000000153e0b4>] dump_stack_lvl+0x88/0xd0 > [ 0.000000] [<90000000002bc548>] register_lock_class+0x768/0x770 > [ 0.000000] [<90000000002bc710>] __lock_acquire+0xb0/0x2a18 > [ 0.000000] [<90000000002bba1c>] lock_acquire+0x11c/0x328 > [ 0.000000] [<9000000000b34a60>] __debug_object_init+0x60/0x244 > [ 0.000000] [<9000000000337f94>] init_cgroup_housekeeping+0xe8/0x144 > [ 0.000000] [<900000000033e364>] init_cgroup_root+0x38/0xa0 > [ 0.000000] [<90000000017801ac>] cgroup_init_early+0x44/0x16c > [ 0.000000] [<9000000001770758>] start_kernel+0x50/0x624 > [ 0.000000] [<90000000015410b4>] kernel_entry+0xb4/0xc4 > > Reverting it fixes the problem. Bisect log attached. > > This is also seen in v6.5.y and v6.4.y since the patch has been applied > to those branches. Does this happens with CONFIG_SMP=n ? If so, I think the untested patch below might fix the issue. Helge --- [PATCH] loogarch: Keep PERCPU section in init section even for !CONFIG_SMP Signed-off-by: Helge Deller <deller@gmx.de> diff --git a/arch/loongarch/kernel/vmlinux.lds.S b/arch/loongarch/kernel/vmlinux.lds.S index b1686afcf876..32d61e931cdc 100644 --- a/arch/loongarch/kernel/vmlinux.lds.S +++ b/arch/loongarch/kernel/vmlinux.lds.S @@ -99,9 +99,7 @@ SECTIONS EXIT_DATA } -#ifdef CONFIG_SMP PERCPU_SECTION(1 << CONFIG_L1_CACHE_SHIFT) -#endif .init.bss : { *(.init.bss) ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] lockdep: Fix static memory detection even more 2023-09-03 21:11 ` [PATCH] lockdep: Fix static memory detection even more Helge Deller @ 2023-09-03 23:08 ` Guenter Roeck 2023-09-06 7:18 ` Helge Deller 0 siblings, 1 reply; 4+ messages in thread From: Guenter Roeck @ 2023-09-03 23:08 UTC (permalink / raw) To: Helge Deller, Linus Torvalds, linux-kernel, linux-fbdev, dri-devel Cc: Andrew Morton, Greg Kroah-Hartman, Rafael J. Wysocki, linux-parisc, Borislav Petkov, Peter Zijlstra On 9/3/23 14:11, Helge Deller wrote: > * Guenter Roeck <linux@roeck-us.net>: >> Hi, >> >> On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote: >>> On the parisc architecture, lockdep reports for all static objects which >>> are in the __initdata section (e.g. "setup_done" in devtmpfs, >>> "kthreadd_done" in init/main.c) this warning: >>> >>> INFO: trying to register non-static key. >>> >>> The warning itself is wrong, because those objects are in the __initdata >>> section, but the section itself is on parisc outside of range from >>> _stext to _end, which is why the static_obj() functions returns a wrong >>> answer. >>> >>> While fixing this issue, I noticed that the whole existing check can >>> be simplified a lot. >>> Instead of checking against the _stext and _end symbols (which include >>> code areas too) just check for the .data and .bss segments (since we check a >>> data object). This can be done with the existing is_kernel_core_data() >>> macro. >>> >>> In addition objects in the __initdata section can be checked with >>> init_section_contains(). >>> >>> This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static >>> memory detection"). >>> >>> Tested on x86-64 and parisc. >>> >>> Signed-off-by: Helge Deller <deller@gmx.de> >>> Fixes: bac59d18c701 ("x86/setup: Fix static memory detection") >> >> On loongarch, this patch results in the following backtrace. >> >> EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path >> EFI stub: Exiting boot services >> [ 0.000000] INFO: trying to register non-static key. >> [ 0.000000] The code is fine but needs lockdep annotation, or maybe >> [ 0.000000] you didn't initialize this object before use? >> [ 0.000000] turning off the locking correctness validator. >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #1 >> [ 0.000000] Stack : 0000000000000000 0000000000000000 9000000000223d6c 9000000001df0000 >> [ 0.000000] 9000000001df39a0 9000000001df39a8 0000000000000000 0000000000000000 >> [ 0.000000] 9000000001df39a8 0000000000000001 0000000000000000 900000000154b910 >> [ 0.000000] fffffffffffffffe 9000000001df39a8 0000000000000000 0000000000000000 >> [ 0.000000] 0000000000000001 0000000000000003 0000000000000010 0000000000000030 >> [ 0.000000] 0000000000000063 0000000000000001 0000000000000000 0000000000000000 >> [ 0.000000] 0000000000000000 0000000000000000 9000000001c60650 9000000001e12000 >> [ 0.000000] 0000000000000000 9000000001560bc0 0000000000000000 9000000002ee6000 >> [ 0.000000] 0000000000000000 0000000000000000 9000000000223d84 0000000000000000 >> [ 0.000000] 00000000000000b0 0000000000000004 0000000000000000 0000000000000800 >> [ 0.000000] ... >> [ 0.000000] Call Trace: >> [ 0.000000] [<9000000000223d84>] show_stack+0x5c/0x180 >> [ 0.000000] [<900000000153e0b4>] dump_stack_lvl+0x88/0xd0 >> [ 0.000000] [<90000000002bc548>] register_lock_class+0x768/0x770 >> [ 0.000000] [<90000000002bc710>] __lock_acquire+0xb0/0x2a18 >> [ 0.000000] [<90000000002bba1c>] lock_acquire+0x11c/0x328 >> [ 0.000000] [<9000000000b34a60>] __debug_object_init+0x60/0x244 >> [ 0.000000] [<9000000000337f94>] init_cgroup_housekeeping+0xe8/0x144 >> [ 0.000000] [<900000000033e364>] init_cgroup_root+0x38/0xa0 >> [ 0.000000] [<90000000017801ac>] cgroup_init_early+0x44/0x16c >> [ 0.000000] [<9000000001770758>] start_kernel+0x50/0x624 >> [ 0.000000] [<90000000015410b4>] kernel_entry+0xb4/0xc4 >> >> Reverting it fixes the problem. Bisect log attached. >> >> This is also seen in v6.5.y and v6.4.y since the patch has been applied >> to those branches. > > Does this happens with CONFIG_SMP=n ? > If so, I think the untested patch below might fix the issue. > No, this is loongarch:defconfig with various debug options enabled. That has CONFIG_SMP=y. Guenter > Helge > > --- > > [PATCH] loogarch: Keep PERCPU section in init section even for !CONFIG_SMP > > Signed-off-by: Helge Deller <deller@gmx.de> > > diff --git a/arch/loongarch/kernel/vmlinux.lds.S b/arch/loongarch/kernel/vmlinux.lds.S > index b1686afcf876..32d61e931cdc 100644 > --- a/arch/loongarch/kernel/vmlinux.lds.S > +++ b/arch/loongarch/kernel/vmlinux.lds.S > @@ -99,9 +99,7 @@ SECTIONS > EXIT_DATA > } > > -#ifdef CONFIG_SMP > PERCPU_SECTION(1 << CONFIG_L1_CACHE_SHIFT) > -#endif > > .init.bss : { > *(.init.bss) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] lockdep: Fix static memory detection even more 2023-09-03 23:08 ` Guenter Roeck @ 2023-09-06 7:18 ` Helge Deller 2023-09-06 8:11 ` Guenter Roeck 0 siblings, 1 reply; 4+ messages in thread From: Helge Deller @ 2023-09-06 7:18 UTC (permalink / raw) To: Guenter Roeck, Linus Torvalds, linux-kernel, linux-fbdev, dri-devel Cc: Andrew Morton, Greg Kroah-Hartman, Rafael J. Wysocki, linux-parisc, Borislav Petkov, Peter Zijlstra * Guenter Roeck <linux@roeck-us.net>: > On 9/3/23 14:11, Helge Deller wrote: > > * Guenter Roeck <linux@roeck-us.net>: > > > Hi, > > > > > > On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote: > > > > On the parisc architecture, lockdep reports for all static objects which > > > > are in the __initdata section (e.g. "setup_done" in devtmpfs, > > > > "kthreadd_done" in init/main.c) this warning: > > > > > > > > INFO: trying to register non-static key. > > > > > > > > The warning itself is wrong, because those objects are in the __initdata > > > > section, but the section itself is on parisc outside of range from > > > > _stext to _end, which is why the static_obj() functions returns a wrong > > > > answer. > > > > > > > > While fixing this issue, I noticed that the whole existing check can > > > > be simplified a lot. > > > > Instead of checking against the _stext and _end symbols (which include > > > > code areas too) just check for the .data and .bss segments (since we check a > > > > data object). This can be done with the existing is_kernel_core_data() > > > > macro. > > > > > > > > In addition objects in the __initdata section can be checked with > > > > init_section_contains(). > > > > > > > > This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static > > > > memory detection"). > > > > > > > > Tested on x86-64 and parisc. > > > > > > > > Signed-off-by: Helge Deller <deller@gmx.de> > > > > Fixes: bac59d18c701 ("x86/setup: Fix static memory detection") > > > > > > On loongarch, this patch results in the following backtrace. > > > > > > EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path > > > EFI stub: Exiting boot services > > > [ 0.000000] INFO: trying to register non-static key. > > > [ 0.000000] The code is fine but needs lockdep annotation, or maybe > > > [ 0.000000] you didn't initialize this object before use? > > > [ 0.000000] turning off the locking correctness validator. > > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #1 > > > [ 0.000000] Stack : 0000000000000000 0000000000000000 9000000000223d6c 9000000001df0000 > > > [ 0.000000] 9000000001df39a0 9000000001df39a8 0000000000000000 0000000000000000 > > > [ 0.000000] 9000000001df39a8 0000000000000001 0000000000000000 900000000154b910 > > > [ 0.000000] fffffffffffffffe 9000000001df39a8 0000000000000000 0000000000000000 > > > [ 0.000000] 0000000000000001 0000000000000003 0000000000000010 0000000000000030 > > > [ 0.000000] 0000000000000063 0000000000000001 0000000000000000 0000000000000000 > > > [ 0.000000] 0000000000000000 0000000000000000 9000000001c60650 9000000001e12000 > > > [ 0.000000] 0000000000000000 9000000001560bc0 0000000000000000 9000000002ee6000 > > > [ 0.000000] 0000000000000000 0000000000000000 9000000000223d84 0000000000000000 > > > [ 0.000000] 00000000000000b0 0000000000000004 0000000000000000 0000000000000800 > > > [ 0.000000] ... > > > [ 0.000000] Call Trace: > > > [ 0.000000] [<9000000000223d84>] show_stack+0x5c/0x180 > > > [ 0.000000] [<900000000153e0b4>] dump_stack_lvl+0x88/0xd0 > > > [ 0.000000] [<90000000002bc548>] register_lock_class+0x768/0x770 > > > [ 0.000000] [<90000000002bc710>] __lock_acquire+0xb0/0x2a18 > > > [ 0.000000] [<90000000002bba1c>] lock_acquire+0x11c/0x328 > > > [ 0.000000] [<9000000000b34a60>] __debug_object_init+0x60/0x244 > > > [ 0.000000] [<9000000000337f94>] init_cgroup_housekeeping+0xe8/0x144 > > > [ 0.000000] [<900000000033e364>] init_cgroup_root+0x38/0xa0 > > > [ 0.000000] [<90000000017801ac>] cgroup_init_early+0x44/0x16c > > > [ 0.000000] [<9000000001770758>] start_kernel+0x50/0x624 > > > [ 0.000000] [<90000000015410b4>] kernel_entry+0xb4/0xc4 > > > > > > Reverting it fixes the problem. Bisect log attached. > > > > > > This is also seen in v6.5.y and v6.4.y since the patch has been applied > > > to those branches. > > > > Does this happens with CONFIG_SMP=n ? > > If so, I think the untested patch below might fix the issue. > > > > No, this is loongarch:defconfig with various debug options enabled. > That has CONFIG_SMP=y. Could you apply below patch and verify with the contents of the System.map file where the lock is located ? diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index e85b5ad3e206..db0a301f9740 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -969,7 +969,7 @@ static bool assign_lock_key(struct lockdep_map *lock) else { /* Debug-check: all keys must be persistent! */ debug_locks_off(); - pr_err("INFO: trying to register non-static key.\n"); + pr_err("INFO: trying to register non-static key at %08lx.\n", addr); pr_err("The code is fine but needs lockdep annotation, or maybe\n"); pr_err("you didn't initialize this object before use?\n"); pr_err("turning off the locking correctness validator.\n"); ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] lockdep: Fix static memory detection even more 2023-09-06 7:18 ` Helge Deller @ 2023-09-06 8:11 ` Guenter Roeck 0 siblings, 0 replies; 4+ messages in thread From: Guenter Roeck @ 2023-09-06 8:11 UTC (permalink / raw) To: Helge Deller, Linus Torvalds, linux-kernel, linux-fbdev, dri-devel Cc: Andrew Morton, Greg Kroah-Hartman, Rafael J. Wysocki, linux-parisc, Borislav Petkov, Peter Zijlstra On 9/6/23 00:18, Helge Deller wrote: > * Guenter Roeck <linux@roeck-us.net>: >> On 9/3/23 14:11, Helge Deller wrote: >>> * Guenter Roeck <linux@roeck-us.net>: >>>> Hi, >>>> >>>> On Sat, Aug 12, 2023 at 05:48:52PM +0200, Helge Deller wrote: >>>>> On the parisc architecture, lockdep reports for all static objects which >>>>> are in the __initdata section (e.g. "setup_done" in devtmpfs, >>>>> "kthreadd_done" in init/main.c) this warning: >>>>> >>>>> INFO: trying to register non-static key. >>>>> >>>>> The warning itself is wrong, because those objects are in the __initdata >>>>> section, but the section itself is on parisc outside of range from >>>>> _stext to _end, which is why the static_obj() functions returns a wrong >>>>> answer. >>>>> >>>>> While fixing this issue, I noticed that the whole existing check can >>>>> be simplified a lot. >>>>> Instead of checking against the _stext and _end symbols (which include >>>>> code areas too) just check for the .data and .bss segments (since we check a >>>>> data object). This can be done with the existing is_kernel_core_data() >>>>> macro. >>>>> >>>>> In addition objects in the __initdata section can be checked with >>>>> init_section_contains(). >>>>> >>>>> This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static >>>>> memory detection"). >>>>> >>>>> Tested on x86-64 and parisc. >>>>> >>>>> Signed-off-by: Helge Deller <deller@gmx.de> >>>>> Fixes: bac59d18c701 ("x86/setup: Fix static memory detection") >>>> >>>> On loongarch, this patch results in the following backtrace. >>>> >>>> EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path >>>> EFI stub: Exiting boot services >>>> [ 0.000000] INFO: trying to register non-static key. >>>> [ 0.000000] The code is fine but needs lockdep annotation, or maybe >>>> [ 0.000000] you didn't initialize this object before use? >>>> [ 0.000000] turning off the locking correctness validator. >>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #1 >>>> [ 0.000000] Stack : 0000000000000000 0000000000000000 9000000000223d6c 9000000001df0000 >>>> [ 0.000000] 9000000001df39a0 9000000001df39a8 0000000000000000 0000000000000000 >>>> [ 0.000000] 9000000001df39a8 0000000000000001 0000000000000000 900000000154b910 >>>> [ 0.000000] fffffffffffffffe 9000000001df39a8 0000000000000000 0000000000000000 >>>> [ 0.000000] 0000000000000001 0000000000000003 0000000000000010 0000000000000030 >>>> [ 0.000000] 0000000000000063 0000000000000001 0000000000000000 0000000000000000 >>>> [ 0.000000] 0000000000000000 0000000000000000 9000000001c60650 9000000001e12000 >>>> [ 0.000000] 0000000000000000 9000000001560bc0 0000000000000000 9000000002ee6000 >>>> [ 0.000000] 0000000000000000 0000000000000000 9000000000223d84 0000000000000000 >>>> [ 0.000000] 00000000000000b0 0000000000000004 0000000000000000 0000000000000800 >>>> [ 0.000000] ... >>>> [ 0.000000] Call Trace: >>>> [ 0.000000] [<9000000000223d84>] show_stack+0x5c/0x180 >>>> [ 0.000000] [<900000000153e0b4>] dump_stack_lvl+0x88/0xd0 >>>> [ 0.000000] [<90000000002bc548>] register_lock_class+0x768/0x770 >>>> [ 0.000000] [<90000000002bc710>] __lock_acquire+0xb0/0x2a18 >>>> [ 0.000000] [<90000000002bba1c>] lock_acquire+0x11c/0x328 >>>> [ 0.000000] [<9000000000b34a60>] __debug_object_init+0x60/0x244 >>>> [ 0.000000] [<9000000000337f94>] init_cgroup_housekeeping+0xe8/0x144 >>>> [ 0.000000] [<900000000033e364>] init_cgroup_root+0x38/0xa0 >>>> [ 0.000000] [<90000000017801ac>] cgroup_init_early+0x44/0x16c >>>> [ 0.000000] [<9000000001770758>] start_kernel+0x50/0x624 >>>> [ 0.000000] [<90000000015410b4>] kernel_entry+0xb4/0xc4 >>>> >>>> Reverting it fixes the problem. Bisect log attached. >>>> >>>> This is also seen in v6.5.y and v6.4.y since the patch has been applied >>>> to those branches. >>> >>> Does this happens with CONFIG_SMP=n ? >>> If so, I think the untested patch below might fix the issue. >>> >> >> No, this is loongarch:defconfig with various debug options enabled. >> That has CONFIG_SMP=y. > > Could you apply below patch and verify with the contents of the > System.map file where the lock is located ? > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index e85b5ad3e206..db0a301f9740 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -969,7 +969,7 @@ static bool assign_lock_key(struct lockdep_map *lock) > else { > /* Debug-check: all keys must be persistent! */ > debug_locks_off(); > - pr_err("INFO: trying to register non-static key.\n"); > + pr_err("INFO: trying to register non-static key at %08lx.\n", addr); > pr_err("The code is fine but needs lockdep annotation, or maybe\n"); > pr_err("you didn't initialize this object before use?\n"); > pr_err("turning off the locking correctness validator.\n"); 90000000015602d0 D __la_abs_end ... 90000000016815c0 d fill_pool_map.3 <--- lock pointer ... 9000000001770000 T __init_begin Guenter ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-06 8:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <ZNep5EcYskP9HtGD@p100>
[not found] ` <b7526bf6-886f-457a-beba-84ae9f75bc77@roeck-us.net>
2023-09-03 21:11 ` [PATCH] lockdep: Fix static memory detection even more Helge Deller
2023-09-03 23:08 ` Guenter Roeck
2023-09-06 7:18 ` Helge Deller
2023-09-06 8:11 ` Guenter Roeck
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).