From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: David Vernet <void@manifault.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yhs@meta.com, john.fastabend@gmail.com, kpsingh@kernel.org,
sdf@google.com, haoluo@google.com, jolsa@kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
tj@kernel.org
Subject: Re: [PATCH bpf-next 4/8] bpf: Enable cpumasks to be queried and used as kptrs
Date: Thu, 19 Jan 2023 21:52:47 -0800 [thread overview]
Message-ID: <20230120055247.obojh465e7pk2rrp@MacBook-Pro-6.local.dhcp.thefacebook.com> (raw)
In-Reply-To: <Y8ort5rBVuHD6cdt@maniforge.lan>
On Thu, Jan 19, 2023 at 11:50:47PM -0600, David Vernet wrote:
> On Thu, Jan 19, 2023 at 09:48:23PM -0800, Alexei Starovoitov wrote:
> > On Thu, Jan 19, 2023 at 05:58:29PM -0600, David Vernet wrote:
> > > silently check for and ignore these cases at runtime. When we have e.g.
> > > per-argument kfunc flags, it might be helpful to add another KF_CPU-type
> > > flag that specifies that the verifier should validate that it's a valid
> > > CPU.
> >
> > ...
> >
> > > +void bpf_cpumask_set_cpu(u32 cpu, struct bpf_cpumask *cpumask)
> > > +{
> > > + if (!cpu_valid(cpu))
> > > + return;
> > > +
> > > + cpumask_set_cpu(cpu, (struct cpumask *)cpumask);
> > > +}
> >
> > ...
> >
> > > +void bpf_cpumask_clear_cpu(u32 cpu, struct bpf_cpumask *cpumask)
> > > +{
> > > + if (!cpu_valid(cpu))
> > > + return;
> >
> > I don't think we'll be able to get rid of this with KF_CPU or special suffix.
> > The argument might be a variable and not a constant at the verification time.
> > We would have to allow passing unknown vars otherwise the UX will be too restrictive,
> > so this run-time check would have to stay.
>
> Makes sense. We'll just leave it as is then and document that passing in
> cpu >= nr_cpus is silently ignored for any kfunc taking a cpu argument.
Eventually we can clean it up with bpf_assert infra.
next prev parent reply other threads:[~2023-01-20 5:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 23:58 [PATCH bpf-next 0/8] Enable cpumasks to be used as kptrs David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 1/8] bpf: Enable annotating trusted nested pointers David Vernet
2023-01-20 1:14 ` kernel test robot
2023-01-20 2:27 ` David Vernet
2023-01-20 6:01 ` kernel test robot
2023-01-19 23:58 ` [PATCH bpf-next 2/8] bpf: Allow trusted args to walk struct when checking BTF IDs David Vernet
2023-01-20 4:58 ` Kumar Kartikeya Dwivedi
2023-01-20 5:23 ` David Vernet
2023-01-20 5:40 ` Alexei Starovoitov
2023-01-20 5:56 ` Kumar Kartikeya Dwivedi
2023-01-20 6:14 ` Alexei Starovoitov
2023-01-20 14:56 ` David Vernet
2023-01-20 15:26 ` David Vernet
2023-01-20 16:17 ` Alexei Starovoitov
2023-01-19 23:58 ` [PATCH bpf-next 3/8] bpf: Disallow NULL PTR_TO_MEM for trusted kfuncs David Vernet
2023-01-20 5:21 ` Kumar Kartikeya Dwivedi
2023-01-20 5:31 ` David Vernet
2023-01-20 5:44 ` Alexei Starovoitov
2023-01-19 23:58 ` [PATCH bpf-next 4/8] bpf: Enable cpumasks to be queried and used as kptrs David Vernet
2023-01-20 2:36 ` kernel test robot
2023-01-20 3:39 ` David Vernet
2023-01-20 5:48 ` Alexei Starovoitov
2023-01-20 5:50 ` David Vernet
2023-01-20 5:52 ` Alexei Starovoitov [this message]
2023-01-20 6:22 ` kernel test robot
2023-01-19 23:58 ` [PATCH bpf-next 5/8] selftests/bpf: Add nested trust selftests suite David Vernet
2023-01-20 5:51 ` Alexei Starovoitov
2023-01-20 5:56 ` David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 6/8] selftests/bpf: Add selftest suite for cpumask kfuncs David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 7/8] bpf/docs: Document cpumask kfuncs in a new file David Vernet
2023-01-20 5:59 ` Alexei Starovoitov
2023-01-20 6:01 ` David Vernet
2023-01-19 23:58 ` [PATCH bpf-next 8/8] bpf/docs: Document how nested trusted fields may be defined David Vernet
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=20230120055247.obojh465e7pk2rrp@MacBook-Pro-6.local.dhcp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=void@manifault.com \
--cc=yhs@meta.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.