From: Yury Norov <yury.norov@gmail.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: x86@kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
openrisc@lists.librecores.org,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning
Date: Sat, 15 Oct 2022 11:08:51 -0700 [thread overview]
Message-ID: <Y0r3M+WCMqugVoXf@yury-laptop> (raw)
In-Reply-To: <20221014155845.1986223-1-ajones@ventanamicro.com>
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: x86@kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
Stafford Horne <shorne@gmail.com>,
openrisc@lists.librecores.org,
Michael Ellerman <mpe@ellerman.id.au>,
linuxppc-dev@lists.ozlabs.org, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning
Date: Sat, 15 Oct 2022 11:08:51 -0700 [thread overview]
Message-ID: <Y0r3M+WCMqugVoXf@yury-laptop> (raw)
In-Reply-To: <20221014155845.1986223-1-ajones@ventanamicro.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Jonas Bonn <jonas@southpole.se>,
linux-s390@vger.kernel.org,
Alexander Gordeev <agordeev@linux.ibm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Heiko Carstens <hca@linux.ibm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
openrisc@lists.librecores.org, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
Thomas Gleixner <tglx@linutronix.de>,
Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning
Date: Sat, 15 Oct 2022 11:08:51 -0700 [thread overview]
Message-ID: <Y0r3M+WCMqugVoXf@yury-laptop> (raw)
In-Reply-To: <20221014155845.1986223-1-ajones@ventanamicro.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Jonas Bonn <jonas@southpole.se>,
linux-s390@vger.kernel.org,
Alexander Gordeev <agordeev@linux.ibm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Paul Walmsley <paul.walmsley@sifive.com>,
Stafford Horne <shorne@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
Thomas Gleixner <tglx@linutronix.de>,
Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v3 0/2] Fix /proc/cpuinfo cpumask warning
Date: Sat, 15 Oct 2022 11:08:51 -0700 [thread overview]
Message-ID: <Y0r3M+WCMqugVoXf@yury-laptop> (raw)
In-Reply-To: <20221014155845.1986223-1-ajones@ventanamicro.com>
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
next prev parent reply other threads:[~2022-10-15 18:09 UTC|newest]
Thread overview: 90+ 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 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` [PATCH v3 1/2] RISC-V: " Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` [PATCH v3 2/2] x86: " Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-14 15:58 ` Andrew Jones
2022-10-28 7:48 ` Andrew Jones
2022-10-28 7:48 ` Andrew Jones
2022-10-28 7:48 ` Andrew Jones
2022-10-28 7:48 ` Andrew Jones
2022-10-28 14:46 ` Yury Norov
2022-10-28 14:46 ` Yury Norov
2022-10-28 14:46 ` Yury Norov
2022-10-28 14:46 ` Yury Norov
2022-10-28 15:03 ` Borislav Petkov
2022-10-28 15:03 ` Borislav Petkov
2022-10-28 15:03 ` Borislav Petkov
2022-10-28 15:03 ` Borislav Petkov
2022-10-28 15:13 ` Yury Norov
2022-10-28 15:13 ` Yury Norov
2022-10-28 16:06 ` Borislav Petkov
2022-10-28 16:06 ` Borislav Petkov
2022-10-28 16:06 ` Borislav Petkov
2022-10-28 16:06 ` Borislav Petkov
2022-10-31 8:06 ` Andrew Jones
2022-10-31 8:06 ` Andrew Jones
2022-10-31 8:06 ` Andrew Jones
2022-10-31 8:06 ` Andrew Jones
2022-10-31 8:58 ` Borislav Petkov
2022-10-31 8:58 ` Borislav Petkov
2022-10-31 8:58 ` Borislav Petkov
2022-10-31 8:58 ` Borislav Petkov
2022-10-31 10:03 ` Andrew Jones
2022-10-31 10:03 ` Andrew Jones
2022-10-31 10:03 ` Andrew Jones
2022-10-31 10:03 ` Andrew Jones
2022-11-02 18:44 ` Borislav Petkov
2022-11-02 18:44 ` Borislav Petkov
2022-11-02 18:44 ` Borislav Petkov
2022-11-02 18:44 ` Borislav Petkov
2022-11-03 12:59 ` Andrew Jones
2022-11-03 12:59 ` Andrew Jones
2022-11-03 12:59 ` Andrew Jones
2022-11-03 12:59 ` Andrew Jones
2022-11-03 15:02 ` Borislav Petkov
2022-11-03 15:02 ` Borislav Petkov
2022-11-03 15:02 ` Borislav Petkov
2022-11-03 15:02 ` Borislav Petkov
2022-11-03 15:34 ` Andrew Jones
2022-11-03 15:34 ` Andrew Jones
2022-11-03 15:34 ` Andrew Jones
2022-11-03 15:34 ` Andrew Jones
2022-11-03 15:54 ` Borislav Petkov
2022-11-03 15:54 ` Borislav Petkov
2022-11-03 15:54 ` Borislav Petkov
2022-11-03 15:54 ` Borislav Petkov
2022-11-03 16:30 ` yury.norov
2022-11-03 16:30 ` yury.norov
2022-11-03 16:30 ` yury.norov
2022-11-03 16:30 ` yury.norov
2022-11-03 16:49 ` Borislav Petkov
2022-11-03 16:49 ` Borislav Petkov
2022-11-03 16:49 ` Borislav Petkov
2022-11-03 16:49 ` Borislav Petkov
2022-11-03 17:31 ` Yury Norov
2022-11-03 17:31 ` Yury Norov
2022-11-03 17:31 ` Yury Norov
2022-11-03 17:31 ` Yury Norov
2022-11-03 23:22 ` Borislav Petkov
2022-11-03 23:22 ` Borislav Petkov
2022-11-03 23:22 ` Borislav Petkov
2022-11-03 23:22 ` Borislav Petkov
2022-10-15 18:08 ` Yury Norov [this message]
2022-10-15 18:08 ` [PATCH v3 0/2] " Yury Norov
2022-10-15 18:08 ` Yury Norov
2022-10-15 18:08 ` Yury Norov
2022-10-27 23:07 ` Palmer Dabbelt
2022-10-27 23:07 ` Palmer Dabbelt
2022-10-27 23:07 ` Palmer Dabbelt
2022-10-27 23:07 ` Palmer Dabbelt
2022-10-28 7:40 ` Andrew Jones
2022-10-28 7:40 ` Andrew Jones
2022-10-28 7:40 ` Andrew Jones
2022-10-28 7:40 ` Andrew Jones
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=Y0r3M+WCMqugVoXf@yury-laptop \
--to=yury.norov@gmail.com \
--cc=agordeev@linux.ibm.com \
--cc=ajones@ventanamicro.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=mpe@ellerman.id.au \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.