On Thu, Oct 27, 2022 at 04:07:18PM -0700, Palmer Dabbelt wrote:
> On Fri, 14 Oct 2022 08:58:43 PDT (-0700), ajones@xxxxxxxxxxxxxxxx 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
