From: Andrew Jones <ajones@ventanamicro.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: jonas@southpole.se, linux-s390@vger.kernel.org,
agordeev@linux.ibm.com, dave.hansen@linux.intel.com,
gor@linux.ibm.com, yury.norov@gmail.com, hca@linux.ibm.com,
x86@kernel.org, linux-kernel@vger.kernel.org,
stefan.kristiansson@saunalahti.fi, openrisc@lists.librecores.org,
mingo@redhat.com, bp@alien8.de,
Paul Walmsley <paul.walmsley@sifive.com>,
shorne@gmail.com, linux-riscv@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, tglx@linutronix.de,
aou@eecs.berkeley.edu
Subject: Re: [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning
Date: Fri, 28 Oct 2022 09:40:37 +0200 [thread overview]
Message-ID: <20221028074037.ksvtvzajyulm3oy2@kamzik> (raw)
In-Reply-To: <mhng-b3bcbdea-1572-44ba-9d9a-e35e55b8880f@palmer-ri-x1c9a>
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
prev parent reply other threads:[~2022-10-28 7:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 15:58 [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning Andrew Jones
2022-10-14 15:58 ` [PATCH v3 1/2] RISC-V: " Andrew Jones
2022-10-14 15:58 ` [PATCH v3 2/2] x86: " Andrew Jones
2022-10-28 7:48 ` Andrew Jones
2022-10-28 14:46 ` Yury Norov
2022-10-28 15:03 ` Borislav Petkov
2022-10-28 15:13 ` Yury Norov
2022-10-28 16:06 ` Borislav Petkov
2022-10-31 8:06 ` Andrew Jones
2022-10-31 8:58 ` Borislav Petkov
2022-10-31 10:03 ` Andrew Jones
2022-11-02 18:44 ` Borislav Petkov
2022-11-03 12:59 ` Andrew Jones
2022-11-03 15:02 ` Borislav Petkov
2022-11-03 15:34 ` Andrew Jones
2022-11-03 15:54 ` Borislav Petkov
2022-11-03 16:30 ` yury.norov
2022-11-03 16:49 ` Borislav Petkov
2022-11-03 17:31 ` Yury Norov
2022-11-03 23:22 ` Borislav Petkov
2022-10-15 18:08 ` [PATCH v3 0/2] " Yury Norov
2022-10-27 23:07 ` Palmer Dabbelt
2022-10-28 7:40 ` Andrew Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221028074037.ksvtvzajyulm3oy2@kamzik \
--to=ajones@ventanamicro.com \
--cc=agordeev@linux.ibm.com \
--cc=aou@eecs.berkeley.edu \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=openrisc@lists.librecores.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=shorne@gmail.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox