On Fri, Jun 19, 2026 at 4:03 PM Paul Chaignon <[email protected]> wrote: > > On Thu, Jun 18, 2026 at 06:45:18PM +0800, sun jian wrote: > > On Thu, Jun 18, 2026 at 4:44 PM Paul Chaignon <[email protected]> > > wrote: > > > > > > On Wed, Jun 17, 2026 at 10:19:52PM +0800, sun jian wrote: > > > > On Wed, Jun 17, 2026 at 6:31 PM <[email protected]> wrote: > > [...] > > > > > I tried reusing pkt_v4 and the existing TC program, but they do not fit > > > > the skb case this test is trying to cover. > > > > > > > > For skb test_run, IPv4/IPv6 inputs with a too-short L3 header in the > > > > linear area are rejected before bpf_test_finish(). With pkt_v4 and a > > > > linear area of ETH_HLEN, the test fails with -EINVAL before reaching the > > > > partial copy-out path. If the linear area is increased enough to pass > > > > the > > > > IPv4 check, pkt_v4 is too small to both trigger the old > > > > copy_size - frag_size path and verify that the copied prefix spans the > > > > linear data and the first fragment. pkt_v6 has the same issue: after > > > > making the IPv6 header linear, only 20 bytes remain in frags. > > > > > > > > The existing test_pkt_access program has its own packet-access coverage > > > > goals and is not just a pass-through carrier. With such a short linear > > > > area or small packet fixture, it can fail before the test hits the > > > > bpf_test_finish()'s partial copy-out path. A pass-through TC program is > > > > therefore a better fit, because it keeps the test focused on the > > > > bpf_test_finish() copy-out semantics. > > > > > > If we're keeping tc_pass_prog() then can't we use pkt_v4 and get rid of > > > init_pkt? > > > > > > > pkt_v4 is too small to construct a meaningful nonlinear skb with a stable > > linear/frag split while still exercising the partial copy-out boundary in > > bpf_test_finish(). > > > > With pkt_v4, we either do not reach a fragmented layout, or lose control > > over > > the linear/frag boundary needed to exercise the regression path. > > I think I'm missing something. Why can't we use pkt_v4 with > tc_pass_prog() and a linear area of ETH_HLEN? That would leave 42 bytes > of non-linear area, so a SHORT_OUT_LEN of 30 should work to trigger the > bug, no? >
I should have made that part clearer. With a linear area of ETH_HLEN, the skb test_run path fails before reaching bpf_test_finish(). After eth_type_trans(), skb->data is advanced past the Ethernet header, so the remaining linear L3 area is 0. The short IPv4 input check then rejects the packet with -EINVAL. To pass that check with pkt_v4, the linear area has to include the IPv4 header as well, i.e. ETH_HLEN + sizeof(struct iphdr). That leaves only about 20 bytes in frags, so a SHORT_OUT_LEN of 30 no longer triggers the old copy_size - frag_size < 0 path. > > > > This test uses a 9000B packet so it does not depend on small-packet > > allocation details. Smaller packets might work depending on allocation > > state, but 9000B reliably gives us a non-linear skb with page frags and a > > stable linear/frag boundary for the copy-out regression. > > > > init_pkt() is needed to ensure deterministic byte content across both linear > > and fragmented regions so that the memcmp-based validation is stable. > > > > Thanks, > > Sun Jian > > > > > > > > > > > > For XDP, this object does not have an existing xdp.frags pass-through > > > > program, so the small XDP frags program is needed to cover the other > > > > caller of the shared bpf_test_finish() path. > > > > > > > > Thanks, > > > > Sun Jian
