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, [email protected] wrote:
> 
> !-------------------------------------------------------------------|
>  This Message Is From an External Sender
>  This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
>> 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.