From: David Vernet <void@manifault.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, song@kernel.org, yhs@fb.com,
john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com,
jolsa@kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, tj@kernel.org, clm@meta.com,
thinker.li@gmail.com, Stanislav Fomichev <sdf@google.com>
Subject: Re: [PATCH bpf-next] bpf: Support default .validate() and .update() behavior for struct_ops links
Date: Mon, 14 Aug 2023 12:45:26 -0500 [thread overview]
Message-ID: <20230814174526.GG542801@maniforge> (raw)
In-Reply-To: <f10dd9ba-de75-c2b1-a7e9-fd71bdc2f0fe@linux.dev>
On Mon, Aug 14, 2023 at 09:55:37AM -0700, Martin KaFai Lau wrote:
> On 8/11/23 4:36 PM, David Vernet wrote:
> > I see, thanks for explaining. This is why sched_ext doesn't really work
> > with the BPF_F_LINK version of map update. We can't guarantee that a map
> > can be updated if we can't succeed in ->reg(), because we can also race
> > with e.g. sysrq unloading the scheduler between ->validate() and
> > ->reg(). In a sense, it feels like ->reg() in "updateable" struct_ops
> > implementations should be void, whereas in other struct_ops
> > implementations like scx() it has to be int *. If validate() is meant to
> > prevent the scenario you outlined, can you help me understand why we
> > still check the return value of ->reg() in bpf_struct_ops_link_create()?
> > Or at the very least it seems like we should WARN_ON()?
>
> ->regs() can fail if another struct_ops under the same
> name has already been loaded to the subsystem. If another
> subsystem needs another return value to support .update, I
> believe it can be done if that is blocking scx to support
> "updateable" link.
Ok, so ->validate() is a static check that should either always succeed
or always fail, and ->reg() may fail due to runtime circumstances. So a
map that passes ->validate() could e.g. retry to create the link in a
loop or something. Or create a series of validated struct_ops maps and
then have a management layer that destroys and creates links for the map
you want to actually use. Thanks for explaining.
> > > If it needs to validate struct_ops as a while,
>
> There was a typo: as a /whole/.
>
> > >
> > > 1. it must be implemented in .validate instead of .reg. Otherwise, it may
> > > end up having an unusable map.
> >
> > Some clarity on this point (why we check ->reg() on the ->validate()
> > path) would help me write this comment more clearly.
>
>
> hmm... where does it check ->reg() on the ->validate() now?
>
> I was meaning the struct_ops supported subsystem should
> validate the struct_ops map in '.validate' instead of in
> the '.reg'.
>
> or I misunderstood the question?
I just meant that I wasn't understanding why we had to check the return
value of ->reg() in bpf_struct_ops_link_create(). Now that I understand
the semantics, I can document them.
next prev parent reply other threads:[~2023-08-14 17:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 22:04 [PATCH bpf-next] bpf: Support default .validate() and .update() behavior for struct_ops links David Vernet
2023-08-10 22:46 ` Stanislav Fomichev
2023-08-10 23:01 ` David Vernet
2023-08-10 23:15 ` Stanislav Fomichev
2023-08-11 17:35 ` Martin KaFai Lau
2023-08-11 18:17 ` Kui-Feng Lee
2023-08-11 20:19 ` David Vernet
2023-08-11 21:25 ` Kui-Feng Lee
2023-08-11 22:49 ` Martin KaFai Lau
2023-08-11 23:12 ` Kui-Feng Lee
2023-08-11 23:34 ` Martin KaFai Lau
2023-08-11 23:36 ` David Vernet
2023-08-14 16:55 ` Martin KaFai Lau
2023-08-14 17:45 ` David Vernet [this message]
2023-08-11 6:22 ` Kui-Feng Lee
2023-08-11 15:10 ` David Vernet
2023-08-11 6:43 ` Yonghong Song
2023-08-11 15:09 ` David Vernet
2023-08-11 15:43 ` Yonghong Song
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=20230814174526.GG542801@maniforge \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--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=thinker.li@gmail.com \
--cc=tj@kernel.org \
--cc=yhs@fb.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.