| Message ID | 20221014155845.1986223-1-ajones@ventanamicro.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix /proc/cpuinfo cpumask warning | expand |
On Fri, Oct 14, 2022 at 05:58:43PM +0200, Andrew Jones wrote: > Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has > started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1 > are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's > start and next seq operations implement a pattern like > > n = cpumask_next(n - 1, mask); > show(n); > while (1) { > ++n; > n = cpumask_next(n - 1, mask); > if (n >= nr_cpu_ids) > break; > show(n); > } > > which will issue the warning when reading /proc/cpuinfo. > > [*] Warnings will only appear with DEBUG_PER_CPU_MAPS enabled. > > This series address the issue for x86 and riscv, but from a quick > grep of cpuinfo seq operations, I think at least openrisc, powerpc, > and s390 also need an equivalent patch. While the test is simple (see > next paragraph) I'm not equipped to test on each architecture. > > To test, just build a kernel with DEBUG_PER_CPU_MAPS enabled, boot to > a shell, do 'cat /proc/cpuinfo', and look for a kernel warning. > > While the patches are being posted together in a series since they're > for two different architectures they don't necessarily need to go > through the same tree. Acked-by: Yury Norov <yury.norov@gmail.com
On Fri, 14 Oct 2022 08:58:43 PDT (-0700), ajones@ventanamicro.com wrote: > Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has > started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1 > are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's > start and next seq operations implement a pattern like > > n = cpumask_next(n - 1, mask); > show(n); > while (1) { > ++n; > n = cpumask_next(n - 1, mask); > if (n >= nr_cpu_ids) > break; > show(n); > } > > which will issue the warning when reading /proc/cpuinfo. > > [*] Warnings will only appear with DEBUG_PER_CPU_MAPS enabled. > > This series address the issue for x86 and riscv, but from a quick > grep of cpuinfo seq operations, I think at least openrisc, powerpc, > and s390 also need an equivalent patch. While the test is simple (see > next paragraph) I'm not equipped to test on each architecture. > > To test, just build a kernel with DEBUG_PER_CPU_MAPS enabled, boot to > a shell, do 'cat /proc/cpuinfo', and look for a kernel warning. > > While the patches are being posted together in a series since they're > for two different architectures they don't necessarily need to go > through the same tree. > > v3: > - Change condition from >= to == in order to still get a warning > for > as that's unexpected. [Yury] > - Picked up tags on the riscv patch > > v2: > - Added all the information I should have in the first place > to the commit message [Boris] > - Changed style of fix [Boris] > > Andrew Jones (2): > RISC-V: Fix /proc/cpuinfo cpumask warning I just took the RISC-V fix, might be worth re-sending the x86 one alone as nobody's replied over there so it may be lost. Thanks! > x86: Fix /proc/cpuinfo cpumask warning > > arch/riscv/kernel/cpu.c | 3 +++ > arch/x86/kernel/cpu/proc.c | 3 +++ > 2 files changed, 6 insertions(+)
On Thu, Oct 27, 2022 at 04:07:18PM -0700, Palmer Dabbelt wrote: > On Fri, 14 Oct 2022 08:58:43 PDT (-0700), ajones@ventanamicro.com wrote: > > Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has > > started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1 > > are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's > > start and next seq operations implement a pattern like > > > > n = cpumask_next(n - 1, mask); > > show(n); > > while (1) { > > ++n; > > n = cpumask_next(n - 1, mask); > > if (n >= nr_cpu_ids) > > break; > > show(n); > > } > > > > which will issue the warning when reading /proc/cpuinfo. > > > > [*] Warnings will only appear with DEBUG_PER_CPU_MAPS enabled. > > > > This series address the issue for x86 and riscv, but from a quick > > grep of cpuinfo seq operations, I think at least openrisc, powerpc, > > and s390 also need an equivalent patch. While the test is simple (see > > next paragraph) I'm not equipped to test on each architecture. > > > > To test, just build a kernel with DEBUG_PER_CPU_MAPS enabled, boot to > > a shell, do 'cat /proc/cpuinfo', and look for a kernel warning. > > > > While the patches are being posted together in a series since they're > > for two different architectures they don't necessarily need to go > > through the same tree. > > > > v3: > > - Change condition from >= to == in order to still get a warning > > for > as that's unexpected. [Yury] > > - Picked up tags on the riscv patch > > > > v2: > > - Added all the information I should have in the first place > > to the commit message [Boris] > > - Changed style of fix [Boris] > > > > Andrew Jones (2): > > RISC-V: Fix /proc/cpuinfo cpumask warning > > I just took the RISC-V fix, might be worth re-sending the x86 one alone as > nobody's replied over there so it may be lost. Thanks Palmer. I still believe this fix is a good idea, or at least not wrong, but as the cpumask change which started the warnings was reverted (commit 80493877d7d0 ("Revert "cpumask: fix checking valid cpu range".")) it seems the urgency for fixes like this one was reduced. I'll ping the x86 patch to see if it's still of interest or not. Thanks, drew
Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1 are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's start and next seq operations implement a pattern like n = cpumask_next(n - 1, mask); show(n); while (1) { ++n; n = cpumask_next(n - 1, mask); if (n >= nr_cpu_ids) break; show(n); } which will issue the warning when reading /proc/cpuinfo. [*] Warnings will only appear with DEBUG_PER_CPU_MAPS enabled. This series address the issue for x86 and riscv, but from a quick grep of cpuinfo seq operations, I think at least openrisc, powerpc, and s390 also need an equivalent patch. While the test is simple (see next paragraph) I'm not equipped to test on each architecture. To test, just build a kernel with DEBUG_PER_CPU_MAPS enabled, boot to a shell, do 'cat /proc/cpuinfo', and look for a kernel warning. While the patches are being posted together in a series since they're for two different architectures they don't necessarily need to go through the same tree. v3: - Change condition from >= to == in order to still get a warning for > as that's unexpected. [Yury] - Picked up tags on the riscv patch v2: - Added all the information I should have in the first place to the commit message [Boris] - Changed style of fix [Boris] Andrew Jones (2): RISC-V: Fix /proc/cpuinfo cpumask warning x86: Fix /proc/cpuinfo cpumask warning arch/riscv/kernel/cpu.c | 3 +++ arch/x86/kernel/cpu/proc.c | 3 +++ 2 files changed, 6 insertions(+)