bpf: bidirectional VLAN support for bpf_fib_lookup()#12798
Closed
kernel-patches-daemon-bpf[bot] wants to merge 4 commits into
Closed
bpf: bidirectional VLAN support for bpf_fib_lookup()#12798kernel-patches-daemon-bpf[bot] wants to merge 4 commits into
kernel-patches-daemon-bpf[bot] wants to merge 4 commits into
Conversation
bpf_fib_lookup() returns the FIB-resolved egress ifindex straight from the fib result. When the egress is a VLAN device, the returned ifindex is the VLAN netdev's, which has no XDP xmit handler; XDP programs that want to forward the frame (e.g. xdp-forward) must instead target the underlying physical device and push the VLAN tag themselves. Today the program has no way to learn either the underlying ifindex or the VLAN tag without maintaining its own VLAN-to-ifindex map in userspace and refreshing it on netlink events. Add BPF_FIB_LOOKUP_VLAN. When the caller sets this flag and the fib result is a VLAN device whose immediate parent is a real (non-VLAN) device in the same network namespace, populate the existing output fields params->h_vlan_proto and params->h_vlan_TCI from the VLAN device and replace params->ifindex with the parent's ifindex. params->h_vlan_TCI carries the VID only, with PCP and DEI bits zero; a consumer wanting to set egress priority writes PCP itself. params->smac is the VLAN device's own address, which can differ from the parent's. Only the immediate parent is resolved, via vlan_dev_priv(dev)->real_dev and not vlan_dev_real_dev(), which walks to the bottom of a stack. When the immediate parent is not a real device in the same namespace, the lookup returns BPF_FIB_LKUP_RET_VLAN_FAILURE and leaves params->ifindex at the input. This covers a stacked VLAN (QinQ), where the immediate parent is itself a VLAN device and one h_vlan_proto/h_vlan_TCI pair cannot describe two tags, and a parent in another network namespace (a VLAN device can be moved while its parent stays), whose ifindex would be meaningless in the caller's namespace. A program that wants the VLAN device's own ifindex re-issues the lookup, with a re-initialized params, without BPF_FIB_LOOKUP_VLAN, so the unreducible case stays distinct from a physical egress. That distinction matters for XDP: a program cannot xmit on a VLAN device, so a success carrying the VLAN ifindex would make it redirect to a device with no ndo_xdp_xmit and drop the frame at xdp_do_flush(). The swap and the vlan fields are written only on the reduce path; other output fields keep their existing behaviour, so a frag-needed result still reports the route mtu in params->mtu_result. BPF_FIB_LOOKUP_VLAN is only useful to XDP, which cannot redirect to a VLAN device. A tc program can redirect to the VLAN device directly, so bpf_skb_fib_lookup() rejects the flag with -EINVAL; bpf_xdp_fib_lookup() accepts it. When the flag is not set, behaviour is unchanged: h_vlan_proto and h_vlan_TCI are zeroed and ifindex is left at the FIB result. The new block is compiled only under CONFIG_VLAN_8021Q since vlan_dev_priv() is not defined otherwise; without that config is_vlan_dev() is constant false and the flag is accepted but never acts. That is safe because no VLAN device can exist there, so every egress is already physical. This lets an XDP redirect target the physical device and learn the tag to push in a single lookup, which xdp-forward's optional VLAN mode (xdp-project/xdp-tools#504) wants from the kernel side. The helper's input semantics are unchanged; the reverse direction (supplying a tag as lookup input) is added in the following patch. Suggested-by: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: David Ahern <dsahern@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
BPF_FIB_LOOKUP_VLAN resolves a VLAN egress. The reverse is also useful: an XDP program receiving a VLAN-tagged frame on a physical device wants the lookup to behave as if the packet had arrived on the corresponding VLAN subinterface, so iif-based policy routing and VRF table selection use the right ingress. Add BPF_FIB_LOOKUP_VLAN_INPUT. When set, params->h_vlan_proto and params->h_vlan_TCI are read as an input VLAN tag and the matching VLAN device of params->ifindex is resolved with __vlan_find_dev_deep_rcu(). The device must be up and in the same network namespace as params->ifindex (a VLAN device can be moved to another netns while registered on its parent; receive would deliver into that other namespace, which a lookup here cannot represent). If params->ifindex is itself a VLAN device, its inner (QinQ) subinterface is matched. For a bond or team, a tag on a port matches no device and returns NOT_FWDED; pass the master's ifindex. The lookup then runs with the resolved device as the ingress; params->ifindex itself is not modified on the input side. When the resolved device is enslaved to a VRF, both the full lookup (via the l3mdev rule) and BPF_FIB_LOOKUP_DIRECT (via l3mdev_fib_table_rcu()) select the VRF's table from the resolved ingress. That follows from feeding the resolved device to the flow as the ingress (fl4.flowi4_iif = dev->ifindex), which is what makes l3mdev resolve the VRF master from the subinterface rather than from params->ifindex. The two failure classes get different treatment on purpose. A h_vlan_proto other than 802.1Q/802.1ad is API misuse and returns -EINVAL, since it would otherwise reach the WARN in vlan_proto_idx() with a program-controlled value. An unmatched VID, a device that is down, or one in another namespace is a data outcome and returns BPF_FIB_LKUP_RET_NOT_FWDED, matching the DIRECT path when fib_get_table() finds no table and mirroring real ingress, where the receive path drops such frames. A VID of 0 (a priority tag) is looked up literally and normally fails the same way; receive instead processes such frames untagged, so callers should not set the flag for priority tags. Proceeding on the physical device for any of these would be fail-open for the policy-routing cases above. The h_vlan fields share a union with tbid, so the flag cannot be combined with BPF_FIB_LOOKUP_TBID. It describes ingress, so it also cannot be combined with BPF_FIB_LOOKUP_OUTPUT. Both combinations return -EINVAL; restricting now keeps a later relaxation backward compatible. Combining with BPF_FIB_LOOKUP_VLAN is allowed: the tag is consumed on the ingress side and the egress tag is written on success. Under !CONFIG_VLAN_8021Q the __vlan_find_dev_deep_rcu() stub returns NULL, so every lookup with a valid proto returns NOT_FWDED, which is correct since no VLAN device can exist. Suggested-by: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
Cover both new VLAN flags in the fib_lookup test. BPF_FIB_LOOKUP_VLAN reduces a VLAN egress to its physical parent plus the tag, and BPF_FIB_LOOKUP_VLAN_INPUT scopes the lookup to a VLAN subinterface. BPF_FIB_LOOKUP_VLAN is XDP-only, since VLAN devices have no XDP xmit; the tc helper rejects it with -EINVAL, which the table runner asserts for every flag arm, and the egress result is checked through bpf_xdp_fib_lookup(). Non-VLAN cases run through both helpers and assert the path-independent results match; the XDP loop also checks dmac and, for the tot_len cases, the route mtu_result, so the VLAN-egress dmac and frag-needed coverage stays even though the tc path no longer reaches it. The egress arms pin the reduction (parent ifindex plus tag, including via a neighbour on the VLAN device, in OUTPUT mode, over a bond, and through a DIRECT|TBID table) and the failure contract: a stacked-VLAN (QinQ) egress returns BPF_FIB_LKUP_RET_VLAN_FAILURE with params->ifindex left at the input. That is distinct from a no-neighbour return, which reports the egress ifindex; only VLAN_FAILURE rewinds params->ifindex, and a guard arm whose input and egress devices differ pins the distinction. The VLAN_FAILURE arms are IPv4; the IPv6 path reaches it through the same shared code, so an IPv6 arm would only re-test that. The input arms use an iif rule that routes one destination to two gateways, so the asserted gateway reveals which device the lookup used as ingress, including VRF table selection through the l3mdev rule and l3mdev_fib_table_rcu(). The VRF arms are IPv4-only: the l3mdev match and table resolution are family-independent core shared by both rule paths, and the IPv6 iif feed is pinned by the IPv6 VLAN input arm. A cross-netns subtest moves a VLAN device into a second netns while it stays registered on its parent and checks both directions fail closed at the boundary. A live-frames subtest (test_fib_lookup_vlan_redirect, with BPF_F_TEST_XDP_LIVE_FRAMES) drives real frames through the native xdp_do_redirect() / xdp_do_flush() path: a reducible egress is redirected to the parent and delivered to its peer, while a QinQ egress is passed to the stack, since redirecting to the VLAN device would drop the frame at flush (no ndo_xdp_xmit). The remaining per-case assertions are in the test table: resolution semantics, the -EINVAL and NOT_FWDED error arms, and the SRC/SKIP_NEIGH combinations. Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Avinash Duduskar <avinash.duduskar@gmail.com>
Author
|
Upstream branch: 9a3a07d |
kernel-patches-daemon-bpf
Bot
force-pushed
the
bpf-next_base
branch
from
3fc5b42 to
e2f5ea7
Compare
Author
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=1126804 irrelevant now. Closing PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: bpf: bidirectional VLAN support for bpf_fib_lookup()
version: 7
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1126804