Hi,
On Fri, 2024-09-27 at 13:31 +0800, Kexy Biscuit wrote:
On 3/19/2024 1:12 AM, John Paul Adrian Glaubitz wrote:
Hi Hucai,
On Mon, 2024-03-18 at 22:21 +0800, Huacai Chen wrote:
Hi, SuperH maintainers,
On Wed, Feb 8, 2023 at 8:59 PM John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
On Thu, 2022-07-14 at 16:41 +0800, 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/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;I build-tested the patch and also booted the patched kernel successfully on my SH-7785LCR board.
Showing the contents of /proc/cpuinfo works fine, too:
root@tirpitz:~> cat /proc/cpuinfo machine : SH7785LCR processor : 0 cpu family : sh4a cpu type : SH7785 cut : 7.x cpu flags : fpu perfctr llsc cache type : split (harvard) icache size : 32KiB (4-way) dcache size : 32KiB (4-way) address sizes : 32 bits physical bogomips : 599.99 root@tirpitz:~>
Tested-by: John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de
I am not sure yet whether the change is also correct as I don't know whether it's possible to change the number of CPUs at runtime on SuperH.
Can this patch be merged? This is the only one still unmerged in the whole series.
Thanks for the reminder. I will pick it up for 6.10.
Got sick this week, so I can't pick up anymore patches for 6.9 and will just send Linus a PR later this week.
Adrian
Gentle ping on this, can we get this patch merged into 6.12?
Thanks a lot for the reminder. Since the merge window is about to close, I'll pick this up for 6.13 as it hasn't been reviewed yet from what I can see.
I will definitely pick it up for 6.13 and I'm sorry for the very long delay.
However, when this patch got posted back then, I wasn't a kernel maintainer yet.
Adrian