When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/mips/kernel/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/proc.c b/arch/mips/kernel/proc.c index 4184d641f05e..33a02f3814f5 100644 --- a/arch/mips/kernel/proc.c +++ b/arch/mips/kernel/proc.c @@ -172,7 +172,7 @@ static void *c_start(struct seq_file *m, loff_t *pos) { unsigned long i = *pos;
- return i < NR_CPUS ? (void *) (i + 1) : NULL; + return i < nr_cpu_ids ? (void *) (i + 1) : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/loongarch/kernel/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/loongarch/kernel/proc.c b/arch/loongarch/kernel/proc.c index e0b5f3b031b1..b12a1f21f864 100644 --- a/arch/loongarch/kernel/proc.c +++ b/arch/loongarch/kernel/proc.c @@ -106,7 +106,7 @@ static void *c_start(struct seq_file *m, loff_t *pos) { unsigned long i = *pos;
- return i < NR_CPUS ? (void *)(i + 1) : NULL; + return i < nr_cpu_ids ? (void *)(i + 1) : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/m68k/kernel/setup_no.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c index 19eea73d3c17..ee03287a386c 100644 --- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos) { - return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL; + return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
Hi Huacai,
Thanks for your patch!
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4
efivarfs on m68k?
EFIVAR_FS depends on EFI depends on !CPU_BIG_ENDIAN
[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn
Does this need a Fixes tag, so we know when the problem was introduced?
--- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos) {
return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL;
return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL;}
include/linux/cpumask.h has:
#if NR_CPUS == 1 #define nr_cpu_ids 1U
so on m68k, both evaluate to the same value?
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, Geert,
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi Huacai,
Thanks for your patch!
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Huacai
cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4
efivarfs on m68k?
EFIVAR_FS depends on EFI depends on !CPU_BIG_ENDIAN
[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn
Does this need a Fixes tag, so we know when the problem was introduced?
--- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -201,7 +201,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos) {
return *pos < NR_CPUS ? ((void *) 0x12345678) : NULL;
return *pos < nr_cpu_ids ? ((void *) 0x12345678) : NULL;}
include/linux/cpumask.h has:
#if NR_CPUS == 1 #define nr_cpu_ids 1Uso on m68k, both evaluate to the same value?
Gr{oetje,eeting}s,
Geert-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Huacai,
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Yes, having consistency is good. But that should be mentioned in the patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in arch/m68k/kernel/setup_mm.c, too.
Thanks!
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, Geert,
On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi Huacai,
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Yes, having consistency is good. But that should be mentioned in the patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in arch/m68k/kernel/setup_mm.c, too.
For no-SMP architectures, it seems c_start() in arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither NR_CPUS, nor nr_cpu_ids)?
Huacai
Thanks!
Gr{oetje,eeting}s,
Geert-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Huacai,
On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Yes, having consistency is good. But that should be mentioned in the patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in arch/m68k/kernel/setup_mm.c, too.
For no-SMP architectures, it seems c_start() in arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither NR_CPUS, nor nr_cpu_ids)?
The advantage of using nr_cpu_ids() is that this is one place less to update when adding SMP support later...
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert and Huacai,
On 2022/7/12 17:13, Geert Uytterhoeven wrote:
Hi Huacai,
On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,
DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Yes, having consistency is good. But that should be mentioned in the patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in arch/m68k/kernel/setup_mm.c, too.
For no-SMP architectures, it seems c_start() in arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither NR_CPUS, nor nr_cpu_ids)?
The advantage of using nr_cpu_ids() is that this is one place less to update when adding SMP support later...
Hmm, so I've been watching m68k development lately (although not as closely as I'd like to, due to lack of vintage hardware at hand), given the current amazing momentum all the hobbyists/developers have been contributing to, SMP is well within reach...
But judging from the intent of this patch series (fixing WARNs on certain configs), and that the triggering condition is currently impossible on m68k (and other non-SMP) platforms, I think cleanups for such arches could come as a separate patch series later. I think the m68k refactoring is reasonable after all, due to my observation above, but for the other non-SMP arches we may want to wait for the respective maintainers' opinions.
Hi, all,
On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui kernel@xen0n.name wrote:
Hi Geert and Huacai,
On 2022/7/12 17:13, Geert Uytterhoeven wrote:
Hi Huacai,
On Tue, Jul 12, 2022 at 11:08 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 5:01 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 10:53 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 4:33 PM Geert Uytterhoeven geert@linux-m68k.org wrote:
On Tue, Jul 12, 2022 at 9:53 AM Huacai Chen chenhuacai@loongson.cn wrote: > When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, DEBUG_PER_CPU_MAPS depends on SMP, which is not supported on m68k, and thus cannot be enabled.
This patch is derived from MIPS and LoongArch, I search all architectures and change those that look the same as MIPS and LoongArch. And the warning message below is also a copy-paste from LoongArch, sorry.
Since M68K doesn't support SMP, then this patch seems to make no difference, but does it make sense to keep consistency across all architectures?
Yes, having consistency is good. But that should be mentioned in the patch description, instead of a scary warning CCed to stable ;-)
BTW, you probably want to update the other copy of c_start() in arch/m68k/kernel/setup_mm.c, too.
For no-SMP architectures, it seems c_start() in arch/m68k/kernel/setup_mm.c is more reasonable (just use 1, neither NR_CPUS, nor nr_cpu_ids)?
The advantage of using nr_cpu_ids() is that this is one place less to update when adding SMP support later...
Hmm, so I've been watching m68k development lately (although not as closely as I'd like to, due to lack of vintage hardware at hand), given the current amazing momentum all the hobbyists/developers have been contributing to, SMP is well within reach...
But judging from the intent of this patch series (fixing WARNs on certain configs), and that the triggering condition is currently impossible on m68k (and other non-SMP) platforms, I think cleanups for such arches could come as a separate patch series later. I think the m68k refactoring is reasonable after all, due to my observation above, but for the other non-SMP arches we may want to wait for the respective maintainers' opinions.
It seems that the best solution is only fix architectures with SMP support and leave others (m68k, microblaze, um) as is. :)
Huacai
On Thu, Jul 14, 2022 at 4:07 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui kernel@xen0n.name wrote:
On 2022/7/12 17:13, Geert Uytterhoeven wrote:
But judging from the intent of this patch series (fixing WARNs on certain configs), and that the triggering condition is currently impossible on m68k (and other non-SMP) platforms, I think cleanups for such arches could come as a separate patch series later. I think the m68k refactoring is reasonable after all, due to my observation above, but for the other non-SMP arches we may want to wait for the respective maintainers' opinions.
It seems that the best solution is only fix architectures with SMP support and leave others (m68k, microblaze, um) as is. :)
I think it probably makes sense to do this as a combined cleanup patch, which I can merge through the asm-generic tree, for all architectures whose maintainer does not pick it up directly. For SMP architectures, it's a bugfix that we probably want backported into stable kernels, while for non-SMP targets it is just a minor cleanup for consistency.
Arnd
Hi, Arnd,
On Thu, Jul 14, 2022 at 2:59 PM Arnd Bergmann arnd@arndb.de wrote:
On Thu, Jul 14, 2022 at 4:07 AM Huacai Chen chenhuacai@gmail.com wrote:
On Tue, Jul 12, 2022 at 6:15 PM WANG Xuerui kernel@xen0n.name wrote:
On 2022/7/12 17:13, Geert Uytterhoeven wrote:
But judging from the intent of this patch series (fixing WARNs on certain configs), and that the triggering condition is currently impossible on m68k (and other non-SMP) platforms, I think cleanups for such arches could come as a separate patch series later. I think the m68k refactoring is reasonable after all, due to my observation above, but for the other non-SMP arches we may want to wait for the respective maintainers' opinions.
It seems that the best solution is only fix architectures with SMP support and leave others (m68k, microblaze, um) as is. :)
I think it probably makes sense to do this as a combined cleanup patch, which I can merge through the asm-generic tree, for all architectures whose maintainer does not pick it up directly. For SMP architectures, it's a bugfix that we probably want backported into stable kernels, while for non-SMP targets it is just a minor cleanup for consistency.
OK, I will send V2 later.
Huacai
Arnd
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/microblaze/kernel/cpu/mb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/kernel/cpu/mb.c b/arch/microblaze/kernel/cpu/mb.c index 9581d194d9e4..689de7f75614 100644 --- a/arch/microblaze/kernel/cpu/mb.c +++ b/arch/microblaze/kernel/cpu/mb.c @@ -137,7 +137,7 @@ static void *c_start(struct seq_file *m, loff_t *pos) { int i = *pos;
- return i < NR_CPUS ? (void *) (i + 1) : NULL; + return i < nr_cpu_ids ? (void *) (i + 1) : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
On 7/12/22 09:52, Huacai Chen wrote:
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn
arch/microblaze/kernel/cpu/mb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/microblaze/kernel/cpu/mb.c b/arch/microblaze/kernel/cpu/mb.c index 9581d194d9e4..689de7f75614 100644 --- a/arch/microblaze/kernel/cpu/mb.c +++ b/arch/microblaze/kernel/cpu/mb.c @@ -137,7 +137,7 @@ static void *c_start(struct seq_file *m, loff_t *pos) { int i = *pos;
- return i < NR_CPUS ? (void *) (i + 1) : NULL;
- return i < nr_cpu_ids ? (void *) (i + 1) : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
As was said in m68k thread commit message should be fixed. MB upstream in not SMP. We have SMP configuration in soc vendor tree but upstream we can't enable DEBUG_PER_CPU_MAPS which depends on SMP. But definitely worth to fix it.
Thanks, Michal
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/sh/kernel/cpu/proc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/kernel/cpu/proc.c b/arch/sh/kernel/cpu/proc.c index a306bcd6b341..5f6d0e827bae 100644 --- a/arch/sh/kernel/cpu/proc.c +++ b/arch/sh/kernel/cpu/proc.c @@ -132,7 +132,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos) { - return *pos < NR_CPUS ? cpu_data + *pos : NULL; + return *pos < nr_cpu_ids ? cpu_data + *pos : NULL; } static void *c_next(struct seq_file *m, void *v, loff_t *pos) {
When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.
[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen chenhuacai@loongson.cn --- arch/um/kernel/um_arch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c index a149a5e9a16a..03177c9907d5 100644 --- a/arch/um/kernel/um_arch.c +++ b/arch/um/kernel/um_arch.c @@ -93,7 +93,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos) { - return *pos < NR_CPUS ? cpu_data + *pos : NULL; + return *pos < nr_cpu_ids ? cpu_data + *pos : NULL; }
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Geert Uytterhoeven -
Huacai Chen -
Huacai Chen -
Michal Simek -
WANG Xuerui