From: Borislav Petkov <bp@alien8.de>
To: yury.norov@gmail.com
Cc: x86@kernel.org, linux-riscv <linux-riscv@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
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>,
"open list:LINUX FOR POWERPC PA SEMI PWRFICIENT"
<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 2/2] x86: Fix /proc/cpuinfo cpumask warning
Date: Thu, 3 Nov 2022 17:49:06 +0100 [thread overview]
Message-ID: <Y2PxAiJ1yNzcUSgs@zn.tnic> (raw)
In-Reply-To: <Y2PsvvOWVs9ZLBsp@yury-laptop>
On Thu, Nov 03, 2022 at 09:30:54AM -0700, yury.norov@gmail.com wrote:a
> Callers should pass sane arguments into internal functions if they
> expect sane output.
What internal function? It's in a global header.
> The API not exported to userspace shouldn't sanity-check all inputs
> arguments.
That doesn't have anything to do with userspace at all.
APIs exported to the rest of the kernel should very well check their
inputs. Otherwise they're not APIs - just some random functions which
are visible to the compiler.
> So, the portable code shouldn't expect from cpumasks more than
> documentation said: for a _valid_ offset cpumask_next() returns next
> set bit or >= nr_cpu_ids.
Lemme quote from my previous mail:
"First make sure cpumask_next()'s valid accepted range has been settled
upon, has been explicitly documented"
So where is that valid range documented?
> cpumask_check() has been broken for years. Attempting to fix it faced
> so much resistance, that I had to revert the patch.
The suggestion on that thread made sense: you first fix the callers and
then the interface. Just like any other "broken" kernel API.
Nothing's stopping you from fixing it properly - it'll just take a while
and if it is such a widely used interface, you probably should come up
with a strategy first how to fix it without impacting current use.
Interfaces and their in-kernel users get refactored constantly.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: yury.norov@gmail.com
Cc: Jonas Bonn <jonas@southpole.se>,
linux-s390@vger.kernel.org,
Alexander Gordeev <agordeev@linux.ibm.com>,
x86@kernel.org, Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
openrisc@lists.librecores.org, Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Stafford Horne <shorne@gmail.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"open list:LINUX FOR POWERPC PA SEMI PWRFICIENT"
<linuxppc-dev@lists.ozlabs.org>,
Thomas Gleixner <tglx@linutronix.de>,
Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v3 2/2] x86: Fix /proc/cpuinfo cpumask warning
Date: Thu, 3 Nov 2022 17:49:06 +0100 [thread overview]
Message-ID: <Y2PxAiJ1yNzcUSgs@zn.tnic> (raw)
In-Reply-To: <Y2PsvvOWVs9ZLBsp@yury-laptop>
On Thu, Nov 03, 2022 at 09:30:54AM -0700, yury.norov@gmail.com wrote:a
> Callers should pass sane arguments into internal functions if they
> expect sane output.
What internal function? It's in a global header.
> The API not exported to userspace shouldn't sanity-check all inputs
> arguments.
That doesn't have anything to do with userspace at all.
APIs exported to the rest of the kernel should very well check their
inputs. Otherwise they're not APIs - just some random functions which
are visible to the compiler.
> So, the portable code shouldn't expect from cpumasks more than
> documentation said: for a _valid_ offset cpumask_next() returns next
> set bit or >= nr_cpu_ids.
Lemme quote from my previous mail:
"First make sure cpumask_next()'s valid accepted range has been settled
upon, has been explicitly documented"
So where is that valid range documented?
> cpumask_check() has been broken for years. Attempting to fix it faced
> so much resistance, that I had to revert the patch.
The suggestion on that thread made sense: you first fix the callers and
then the interface. Just like any other "broken" kernel API.
Nothing's stopping you from fixing it properly - it'll just take a while
and if it is such a widely used interface, you probably should come up
with a strategy first how to fix it without impacting current use.
Interfaces and their in-kernel users get refactored constantly.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: yury.norov@gmail.com
Cc: x86@kernel.org, linux-riscv <linux-riscv@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
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>,
"open list:LINUX FOR POWERPC PA SEMI PWRFICIENT"
<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 2/2] x86: Fix /proc/cpuinfo cpumask warning
Date: Thu, 3 Nov 2022 17:49:06 +0100 [thread overview]
Message-ID: <Y2PxAiJ1yNzcUSgs@zn.tnic> (raw)
In-Reply-To: <Y2PsvvOWVs9ZLBsp@yury-laptop>
On Thu, Nov 03, 2022 at 09:30:54AM -0700, yury.norov@gmail.com wrote:a
> Callers should pass sane arguments into internal functions if they
> expect sane output.
What internal function? It's in a global header.
> The API not exported to userspace shouldn't sanity-check all inputs
> arguments.
That doesn't have anything to do with userspace at all.
APIs exported to the rest of the kernel should very well check their
inputs. Otherwise they're not APIs - just some random functions which
are visible to the compiler.
> So, the portable code shouldn't expect from cpumasks more than
> documentation said: for a _valid_ offset cpumask_next() returns next
> set bit or >= nr_cpu_ids.
Lemme quote from my previous mail:
"First make sure cpumask_next()'s valid accepted range has been settled
upon, has been explicitly documented"
So where is that valid range documented?
> cpumask_check() has been broken for years. Attempting to fix it faced
> so much resistance, that I had to revert the patch.
The suggestion on that thread made sense: you first fix the callers and
then the interface. Just like any other "broken" kernel API.
Nothing's stopping you from fixing it properly - it'll just take a while
and if it is such a widely used interface, you probably should come up
with a strategy first how to fix it without impacting current use.
Interfaces and their in-kernel users get refactored constantly.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
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: Borislav Petkov <bp@alien8.de>
To: yury.norov@gmail.com
Cc: Jonas Bonn <jonas@southpole.se>,
linux-s390@vger.kernel.org,
Alexander Gordeev <agordeev@linux.ibm.com>,
x86@kernel.org, Vasily Gorbik <gor@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Heiko Carstens <hca@linux.ibm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
openrisc@lists.librecores.org, Ingo Molnar <mingo@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"open list:LINUX FOR POWERPC PA SEMI PWRFICIENT"
<linuxppc-dev@lists.ozlabs.org>,
Thomas Gleixner <tglx@linutronix.de>,
Albert Ou <aou@eecs.berkeley.edu>
Subject: Re: [PATCH v3 2/2] x86: Fix /proc/cpuinfo cpumask warning
Date: Thu, 3 Nov 2022 17:49:06 +0100 [thread overview]
Message-ID: <Y2PxAiJ1yNzcUSgs@zn.tnic> (raw)
In-Reply-To: <Y2PsvvOWVs9ZLBsp@yury-laptop>
On Thu, Nov 03, 2022 at 09:30:54AM -0700, yury.norov@gmail.com wrote:a
> Callers should pass sane arguments into internal functions if they
> expect sane output.
What internal function? It's in a global header.
> The API not exported to userspace shouldn't sanity-check all inputs
> arguments.
That doesn't have anything to do with userspace at all.
APIs exported to the rest of the kernel should very well check their
inputs. Otherwise they're not APIs - just some random functions which
are visible to the compiler.
> So, the portable code shouldn't expect from cpumasks more than
> documentation said: for a _valid_ offset cpumask_next() returns next
> set bit or >= nr_cpu_ids.
Lemme quote from my previous mail:
"First make sure cpumask_next()'s valid accepted range has been settled
upon, has been explicitly documented"
So where is that valid range documented?
> cpumask_check() has been broken for years. Attempting to fix it faced
> so much resistance, that I had to revert the patch.
The suggestion on that thread made sense: you first fix the callers and
then the interface. Just like any other "broken" kernel API.
Nothing's stopping you from fixing it properly - it'll just take a while
and if it is such a widely used interface, you probably should come up
with a strategy first how to fix it without impacting current use.
Interfaces and their in-kernel users get refactored constantly.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2022-11-03 16:50 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 [this message]
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 ` [PATCH v3 0/2] " Yury Norov
2022-10-15 18:08 ` 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=Y2PxAiJ1yNzcUSgs@zn.tnic \
--to=bp@alien8.de \
--cc=agordeev@linux.ibm.com \
--cc=aou@eecs.berkeley.edu \
--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 \
--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 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.