From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Stanislav Fomichev <stfomichev@gmail.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] bpf: Allow XDP dev-bound programs to perform XDP_REDIRECT into maps
Date: Fri, 25 Apr 2025 09:48:35 +0200 [thread overview]
Message-ID: <87ikms7kbw.fsf@toke.dk> (raw)
In-Reply-To: <aAphqn-Lm0nn4FH0@mini-arch>
Stanislav Fomichev <stfomichev@gmail.com> writes:
> On 04/24, Toke Høiland-Jørgensen wrote:
>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>>
>> > In the current implementation if the program is dev-bound to a specific
>> > device, it will not be possible to perform XDP_REDIRECT into a DEVMAP
>> > or CPUMAP even if the program is running in the driver NAPI context and
>> > it is not attached to any map entry. This seems in contrast with the
>> > explanation available in bpf_prog_map_compatible routine.
>> > Fix the issue introducing __bpf_prog_map_compatible utility routine in
>> > order to avoid bpf_prog_is_dev_bound() check running bpf_check_tail_call()
>> > at program load time (bpf_prog_select_runtime()).
>> > Continue forbidding to attach a dev-bound program to XDP maps
>> > (BPF_MAP_TYPE_PROG_ARRAY, BPF_MAP_TYPE_DEVMAP and BPF_MAP_TYPE_CPUMAP).
>> >
>> > Fixes: 3d76a4d3d4e59 ("bpf: XDP metadata RX kfuncs")
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>> > ---
>> > Changes in v2:
>> > - Introduce __bpf_prog_map_compatible() utility routine in order to skip
>> > bpf_prog_is_dev_bound check in bpf_check_tail_call()
>> > - Extend xdp_metadata selftest
>> > - Link to v1: https://lore.kernel.org/r/20250422-xdp-prog-bound-fix-v1-1-0b581fa186fe@kernel.org
>> > ---
>> > kernel/bpf/core.c | 27 +++++++++++++---------
>> > .../selftests/bpf/prog_tests/xdp_metadata.c | 22 +++++++++++++++++-
>> > tools/testing/selftests/bpf/progs/xdp_metadata.c | 13 +++++++++++
>> > 3 files changed, 50 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> > index ba6b6118cf504041278d05417c4212d57be6fca0..a3e571688421196c3ceaed62b3b59b62a0258a8c 100644
>> > --- a/kernel/bpf/core.c
>> > +++ b/kernel/bpf/core.c
>> > @@ -2358,8 +2358,8 @@ static unsigned int __bpf_prog_ret0_warn(const void *ctx,
>> > return 0;
>> > }
>> >
>> > -bool bpf_prog_map_compatible(struct bpf_map *map,
>> > - const struct bpf_prog *fp)
>> > +static bool __bpf_prog_map_compatible(struct bpf_map *map,
>> > + const struct bpf_prog *fp)
>> > {
>> > enum bpf_prog_type prog_type = resolve_prog_type(fp);
>> > bool ret;
>> > @@ -2368,14 +2368,6 @@ bool bpf_prog_map_compatible(struct bpf_map *map,
>> > if (fp->kprobe_override)
>> > return false;
>> >
>> > - /* XDP programs inserted into maps are not guaranteed to run on
>> > - * a particular netdev (and can run outside driver context entirely
>> > - * in the case of devmap and cpumap). Until device checks
>> > - * are implemented, prohibit adding dev-bound programs to program maps.
>> > - */
>> > - if (bpf_prog_is_dev_bound(aux))
>> > - return false;
>> > -
>> > spin_lock(&map->owner.lock);
>> > if (!map->owner.type) {
>> > /* There's no owner yet where we could check for
>> > @@ -2409,6 +2401,19 @@ bool bpf_prog_map_compatible(struct bpf_map *map,
>> > return ret;
>> > }
>> >
>> > +bool bpf_prog_map_compatible(struct bpf_map *map, const struct bpf_prog *fp)
>> > +{
>> > + /* XDP programs inserted into maps are not guaranteed to run on
>> > + * a particular netdev (and can run outside driver context entirely
>> > + * in the case of devmap and cpumap). Until device checks
>> > + * are implemented, prohibit adding dev-bound programs to program maps.
>> > + */
>> > + if (bpf_prog_is_dev_bound(fp->aux))
>> > + return false;
>> > +
>> > + return __bpf_prog_map_compatible(map, fp);
>> > +}
>> > +
>> > static int bpf_check_tail_call(const struct bpf_prog *fp)
>> > {
>> > struct bpf_prog_aux *aux = fp->aux;
>> > @@ -2421,7 +2426,7 @@ static int bpf_check_tail_call(const struct bpf_prog *fp)
>> > if (!map_type_contains_progs(map))
>> > continue;
>> >
>> > - if (!bpf_prog_map_compatible(map, fp)) {
>> > + if (!__bpf_prog_map_compatible(map, fp)) {
>>
>> Hmm, so this allows devbound programs in tail call maps, right? But
>> there's no guarantee that a tail call map will always be used for a
>> particular device, is there? For instance, it could be shared between
>> multiple XDP programs, bound to different devices, thus getting the
>> wrong kfunc.
>
> Won't this (devbound progs in tail call maps) be still prohibited
> by a bpf_prog_map_compatible check in prog_fd_array_get_ptr?
Yeah, you're right, I misremembered the check and somehow convinced
myself that the check in bpf_check_tail_call() was the one that
prevented dev-bound programs from being loaded into tail call maps...
-Toke
next prev parent reply other threads:[~2025-04-25 7:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 17:44 [PATCH bpf-next v2] bpf: Allow XDP dev-bound programs to perform XDP_REDIRECT into maps Lorenzo Bianconi
2025-04-23 20:29 ` Stanislav Fomichev
2025-04-23 22:29 ` Martin KaFai Lau
2025-04-24 20:27 ` Lorenzo Bianconi
2025-04-24 9:46 ` Toke Høiland-Jørgensen
2025-04-24 16:07 ` Stanislav Fomichev
2025-04-25 7:48 ` Toke Høiland-Jørgensen [this message]
2025-04-24 20:47 ` Lorenzo Bianconi
2025-04-25 7:49 ` Toke Høiland-Jørgensen
2025-04-24 15:39 ` Jesper Dangaard Brouer
2025-04-24 21:02 ` Lorenzo Bianconi
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=87ikms7kbw.fsf@toke.dk \
--to=toke@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=stfomichev@gmail.com \
--cc=yonghong.song@linux.dev \
/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.