Subject: Re: [PATCH v5 6/6] selftests/bpf: tc_tunnel validate decap GSO state

From: Martin KaFai Lau <[email-masked]>
Date: Mon, 27 Apr 2026 15:36:03 -0700

On Mon, Apr 20, 2026 at 11:19:30AM +0000, [email-masked] wrote:
> > +	if (!shinfo->gso_size)
> > +		return TC_ACT_OK;
> > +
> > +	if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
> > +	    (shinfo->gso_type & SKB_GSO_UDP_TUNNEL_MASK))
> > +		return TC_ACT_SHOT;
> > +
> > +	if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE) &&
> > +	    (shinfo->gso_type & (SKB_GSO_GRE | SKB_GSO_GRE_CSUM)))
> > +		return TC_ACT_SHOT;
> > +
> > +	if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4) &&
> > +	    (shinfo->gso_type & SKB_GSO_IPXIP4))
> > +		return TC_ACT_SHOT;
> > +
> > +	if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6) &&
> > +	    (shinfo->gso_type & SKB_GSO_IPXIP6))
> > +		return TC_ACT_SHOT;
> 
> Are these IPXIP4 and IPXIP6 checks reachable?
> 
> Looking earlier in decap_internal(), for IPPROTO_IPIP and IPPROTO_IPV6
> cases, the function only sets BPF_F_ADJ_ROOM_DECAP_L3_IPV4 and
> BPF_F_ADJ_ROOM_DECAP_L3_IPV6 on the flags variable (around the protocol
> switch statement).
> 
> Because BPF_F_ADJ_ROOM_DECAP_IPXIP4 and BPF_F_ADJ_ROOM_DECAP_IPXIP6 are
> never added to flags, wouldn't these validation checks always be skipped?
> 
> Ref: https://lore.kernel.org/bpf/[email-masked]/

This comment has been mentioned again. It seems legit. Please don't ignore
the review comment. Otherwise, it will be assumed that the solutions are
being worked on and patchwork will eventually archive the patches after
some time.

Also, there is a 'SYS(fail_close_ns_client, "ethtool -K veth1 tso off");'
in prog_tests/test_tc_tunnel.c. Is the shinfo->gso_type ever set?
What will break if tso is kept on?