From: Avinash Duduskar <avinash.duduskar@gmail.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Cc: eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org,
emil@etsalapatis.com, john.fastabend@gmail.com, sdf@fomichev.me,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, shuah@kernel.org,
hawk@kernel.org, yatsenko@meta.com, leon.hwang@linux.dev,
kpsingh@kernel.org, a.s.protopopov@gmail.com,
ameryhung@gmail.com, rongtao@cestc.cn, eyal.birger@gmail.com,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
toke@redhat.com, dsahern@kernel.org
Subject: [PATCH bpf-next v5 0/3] bpf: bidirectional VLAN support for bpf_fib_lookup()
Date: Wed, 24 Jun 2026 08:35:27 +0530 [thread overview]
Message-ID: <20260624030530.3342884-1-avinash.duduskar@gmail.com> (raw)
This series adds VLAN awareness to bpf_fib_lookup() in both directions.
BPF_FIB_LOOKUP_VLAN resolves a VLAN egress to its underlying real device
plus the VLAN tag (XDP programs need this because VLAN devices have no XDP
xmit), and BPF_FIB_LOOKUP_VLAN_INPUT runs the lookup as if a tagged frame
had arrived on the matching VLAN subinterface, for iif policy routing and
VRF table selection.
The independent l3mdev/VRF flow-init fix, patch 1 in v1 and v2, was split
out and merged to bpf separately.
An unreducible VLAN egress (a QinQ egress, or a parent in another
namespace) returns BPF_FIB_LKUP_RET_VLAN_FAILURE rather than a best-effort
SUCCESS, so an XDP program cannot mistake it for a physical egress and
silently blackhole the frame at xdp_do_flush(). The code is appended after
BPF_FIB_LKUP_RET_NO_SRC_ADDR (nothing renumbered, tools/ mirror updated)
and is returned only when BPF_FIB_LOOKUP_VLAN is set, so no existing caller
can observe it. On that failure params->ifindex is left at the input; a
program that wants the VLAN device's own ifindex re-issues without the flag.
Changes v4 -> v5 (Toke's review,
https://lore.kernel.org/bpf/87y0g5ca7x.fsf@toke.dk/):
- Patch 1: BPF_FIB_LOOKUP_VLAN only makes sense for XDP, which cannot
redirect to a VLAN device; a tc program can redirect to the VLAN device
directly. So bpf_skb_fib_lookup() now rejects the flag with -EINVAL, and
the fwd_dev out-parameter added in v4 is dropped: with the flag gone from
the skb path there is no swap to preserve, so the deferred mtu check
returns to the original dev_get_by_index_rcu(net, params->ifindex). The
VLAN_FAILURE rewind moves into bpf_fib_set_fwd_params() via an input
ifindex parameter, so each lookup ends in a plain
"return bpf_fib_set_fwd_params(...)". The early params->ifindex =
dev->ifindex that NO_NEIGH and NO_SRC_ADDR report stays where
d1c362e1dd68a ("bpf: Always return target ifindex in bpf_fib_lookup") put
it. Dropping fwd_dev also removes the i386 W=1 unused-variable warning the
kernel test robot reported, since net is used again.
- Patch 2: no code change; add Toke's Reviewed-by.
- Patch 3: the BPF_FIB_LOOKUP_VLAN cases assert the tc helper returns
-EINVAL and check the egress result on the XDP path, including dmac and
(for tot_len cases) the route mtu_result; the cross-netns egress case
runs through bpf_xdp_fib_lookup(); the obsolete skb-mtu-after-swap arm is
dropped.
Changes v3 -> v4:
- Patch 1: return BPF_FIB_LKUP_RET_VLAN_FAILURE for an unreducible VLAN
egress, leaving params->ifindex at the input, per Toke's v3 review.
- Patch 3: QinQ-egress and cross-namespace-egress arms expect VLAN_FAILURE;
an escape-hatch arm re-issues without the flag; and a live-frames arm
asserts a reducible egress is delivered and a QinQ egress is passed to
the stack.
Taking the tag as lookup input follows the approach David Ahern suggested
in the 2021 fwmark discussion:
https://lore.kernel.org/bpf/6248c547-ad64-04d6-fcec-374893cc1ef2@gmail.com/
v4: https://lore.kernel.org/all/20260623025147.1001664-1-avinash.duduskar@gmail.com/
v3: https://lore.kernel.org/all/20260617224729.1428662-1-avinash.duduskar@gmail.com/
v2: https://lore.kernel.org/all/20260616223426.3568080-1-avinash.duduskar@gmail.com/
v1: https://lore.kernel.org/all/20260609172052.81613-1-avinash.duduskar@gmail.com/
Avinash Duduskar (3):
bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
bpf: Add BPF_FIB_LOOKUP_VLAN_INPUT flag to bpf_fib_lookup() helper
selftests/bpf: Add bpf_fib_lookup() VLAN flag tests
include/uapi/linux/bpf.h | 50 +-
net/core/filter.c | 97 ++-
tools/include/uapi/linux/bpf.h | 50 +-
.../selftests/bpf/prog_tests/fib_lookup.c | 717 +++++++++++++++++-
.../testing/selftests/bpf/progs/fib_lookup.c | 36 +
5 files changed, 936 insertions(+), 14 deletions(-)
base-commit: a975094bf98ca97be9146f9d3b5681a6f9cf5ce3
--
2.54.0
next reply other threads:[~2026-06-24 3:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 3:05 Avinash Duduskar [this message]
2026-06-24 3:05 ` [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper Avinash Duduskar
2026-06-24 9:33 ` Toke Høiland-Jørgensen
2026-06-24 11:54 ` Avinash Duduskar
2026-06-24 3:05 ` [PATCH bpf-next v5 2/3] bpf: Add BPF_FIB_LOOKUP_VLAN_INPUT " Avinash Duduskar
2026-06-24 3:05 ` [PATCH bpf-next v5 3/3] selftests/bpf: Add bpf_fib_lookup() VLAN flag tests Avinash Duduskar
2026-06-24 3:15 ` sashiko-bot
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=20260624030530.3342884-1-avinash.duduskar@gmail.com \
--to=avinash.duduskar@gmail.com \
--cc=a.s.protopopov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=emil@etsalapatis.com \
--cc=eyal.birger@gmail.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rongtao@cestc.cn \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=toke@redhat.com \
--cc=yatsenko@meta.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.