From: Yury Norov <yury.norov@gmail.com>
To: Borislav Petkov <bp@alien8.de>
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 10:31:30 -0700 [thread overview]
Message-ID: <Y2P68sfCJMvhKmhj@yury-laptop> (raw)
In-Reply-To: <Y2PxAiJ1yNzcUSgs@zn.tnic>
On Thu, Nov 03, 2022 at 05:49:06PM +0100, Borislav Petkov wrote:
> 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.
Let's take for example cpu_llc_shared_mask() added by you in
arch/x86/include/asm/smp.h recently:
static inline struct cpumask *cpu_llc_shared_mask(int cpu)
{
return per_cpu(cpu_llc_shared_map, cpu);
}
It's in a global header and available to the rest of the kernel, just as
well. How does it check its input? Maybe I lost something important in
per_cpu() internals, but at the first glance, there's no any protection
against -1, nr_cpu_ids, and other out-of-range arguments.
_______________________________________________
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: Borislav Petkov <bp@alien8.de>
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 10:31:30 -0700 [thread overview]
Message-ID: <Y2P68sfCJMvhKmhj@yury-laptop> (raw)
In-Reply-To: <Y2PxAiJ1yNzcUSgs@zn.tnic>
On Thu, Nov 03, 2022 at 05:49:06PM +0100, Borislav Petkov wrote:
> 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.
Let's take for example cpu_llc_shared_mask() added by you in
arch/x86/include/asm/smp.h recently:
static inline struct cpumask *cpu_llc_shared_mask(int cpu)
{
return per_cpu(cpu_llc_shared_map, cpu);
}
It's in a global header and available to the rest of the kernel, just as
well. How does it check its input? Maybe I lost something important in
per_cpu() internals, but at the first glance, there's no any protection
against -1, nr_cpu_ids, and other out-of-range arguments.
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Borislav Petkov <bp@alien8.de>
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 10:31:30 -0700 [thread overview]
Message-ID: <Y2P68sfCJMvhKmhj@yury-laptop> (raw)
In-Reply-To: <Y2PxAiJ1yNzcUSgs@zn.tnic>
On Thu, Nov 03, 2022 at 05:49:06PM +0100, Borislav Petkov wrote:
> 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.
Let's take for example cpu_llc_shared_mask() added by you in
arch/x86/include/asm/smp.h recently:
static inline struct cpumask *cpu_llc_shared_mask(int cpu)
{
return per_cpu(cpu_llc_shared_map, cpu);
}
It's in a global header and available to the rest of the kernel, just as
well. How does it check its input? Maybe I lost something important in
per_cpu() internals, but at the first glance, there's no any protection
against -1, nr_cpu_ids, and other out-of-range arguments.
WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Borislav Petkov <bp@alien8.de>
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 10:31:30 -0700 [thread overview]
Message-ID: <Y2P68sfCJMvhKmhj@yury-laptop> (raw)
In-Reply-To: <Y2PxAiJ1yNzcUSgs@zn.tnic>
On Thu, Nov 03, 2022 at 05:49:06PM +0100, Borislav Petkov wrote:
> 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.
Let's take for example cpu_llc_shared_mask() added by you in
arch/x86/include/asm/smp.h recently:
static inline struct cpumask *cpu_llc_shared_mask(int cpu)
{
return per_cpu(cpu_llc_shared_map, cpu);
}
It's in a global header and available to the rest of the kernel, just as
well. How does it check its input? Maybe I lost something important in
per_cpu() internals, but at the first glance, there's no any protection
against -1, nr_cpu_ids, and other out-of-range arguments.
next prev parent reply other threads:[~2022-11-03 17:32 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 [this message]
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=Y2P68sfCJMvhKmhj@yury-laptop \
--to=yury.norov@gmail.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=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.