On Tue, 27 Oct 2026 09:25:59 +0100 Eric Dumazet wrote: > eth_type_trans() assumes ETH_HLEN bytes are present in skb->head. > NIC drivers always provide this, and they should keep using the fast > version, without an extra pskb_may_pull(). > > Devices looping skbs from their transmit path back to their receive > path get skbs built by the stack instead. tc actions (act_vlan pop_eth, > act_ife decode), BPF helpers (bpf_skb_change_head() before a redirect) > or OVS actions (pop_eth followed by pop_mpls/pop_nsh) can leave fewer > than ETH_HLEN bytes in the linear part, and eth_type_trans() then hits > the BUG() in __skb_pull(). > > Instead of fixing every producer, or adding a check to all > eth_type_trans() users, fix the few consumers exposed to this:
Bot says: BPF CI (bpf-ci) is reporting a consistent regression with this patch applied: every single job variant (x86-64/aarch64/s390x, gcc/llvm, no-alu32/cpuv4/ASAN) fails the exact same selftest subtest: #135 empty_skb Specifically, the "veth ETH_HLEN+1 packet ingress [redirect_ingress]" case in tools/testing/selftests/bpf/prog_tests/empty_skb.c now fails: test_empty_skb:FAIL:ret: veth ETH_HLEN+1 packet ingress [redirect_ingress] unexpected ret: actual 1 != expected 0 That test redirects a minimal (ETH_HLEN+1-byte) skb to a veth's RX path via bpf_clone_redirect(..., BPF_F_INGRESS), which goes through dev_forward_skb() -> __dev_forward_skb2(). Before this change the skb was forwarded successfully (ret == 0); after switching to eth_type_trans_careful() it is now dropped (actual == 1, i.e. NET_RX_DROP). Could you take a look at whether the new drop-on-failure behavior in __dev_forward_skb2() is intentional for this previously-accepted ETH_HLEN+1 packet, and if so, update the empty_skb selftest's expected return value alongside this change? Right now the selftest and the new kernel behavior disagree, and it's failing 100% of the time in CI on every arch/toolchain/config combination we run. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
