Re: [PATCH bpf-next v7 5/6] bpf: clear decap state on skb_adjust_room shrink path

On Aug 12, 2026, at 11:33 AM, bot+bpf-ci@kernel.org wrote:

!-------------------------------------------------------------------|
 This Message Is From an External Sender
 This message came from outside your organization.
|-------------------------------------------------------------------!

quoted

On shrink in bpf_skb_adjust_room(), apply decapsulation state updates
according to BPF_F_ADJ_ROOM_DECAP_* flags.

For GSO skbs, clear only the tunnel gso_type bits that correspond to the
requested decap layer:
- DECAP_L4_UDP: SKB_GSO_UDP_TUNNEL{,_CSUM}
- DECAP_L4_GRE: SKB_GSO_GRE{,_CSUM}
- DECAP_IPXIP4: SKB_GSO_IPXIP4
- DECAP_IPXIP6: SKB_GSO_IPXIP6

Then clear skb->encapsulation only if no tunnel GSO bits remain, keeping
encapsulation set for cases such as ESP-in-UDP where tunnel state remains.

For non-GSO skbs, there are no tunnel GSO bits to consult, so clear
skb->encapsulation directly when DECAP_L4_* or DECAP_IPXIP_* flags are set.

This keeps decap state handling consistent between GSO and non-GSO packets.

This looks like a bug fix for the DECAP flags added in commit 0e08a219f910.
That commit added the BPF_F_ADJ_ROOM_DECAP_* flags and documented that they
would clear GSO state and encapsulation flags, but the behavior was never
implemented in the code. This commit implements that documented behavior.

Should this include:

 Fixes: 0e08a219f910 ("bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation")

The 0e08a219f910 commit only introduces the flags and their documentation. The subsequent patches in this series implement the documented behavior. The split is intentional to aid human review, so no Fixes tag is needed here.