Re: [PATCH bpf-next v7 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation

> On Aug 12, 2026, at 11:33 AM, [email protected] wrote:
> 
>> bpf: refactor masks for ADJ_ROOM flags and encap validation
>> 
>> Refactor the helper masks for bpf_skb_adjust_room() flags to simplify
>> validation logic and introduce:
>> 
>> - BPF_F_ADJ_ROOM_ENCAP_MASK
>> - BPF_F_ADJ_ROOM_DECAP_MASK
>> 
>> Refactor existing validation checks in bpf_skb_net_shrink()
>> and bpf_skb_adjust_room() to use the new masks (no behavior change).
> 
> Does the subject line accurately describe what is being refactored?
> 
> The subject claims the patch refactors "encap validation", but no encap
> validation is refactored anywhere in the diff. The only encap validation
> in this file is in bpf_skb_net_grow() (around the middle of filter.c),
> and it is untouched. It still open-codes the pairwise mutual-exclusion
> tests:
> 
>    if (flags & BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 &&
>        flags & BPF_F_ADJ_ROOM_ENCAP_L3_IPV6)
>            return -EINVAL;
>    if (flags & BPF_F_ADJ_ROOM_ENCAP_L4_GRE &&
>        flags & BPF_F_ADJ_ROOM_ENCAP_L4_UDP)
>            return -EINVAL;
> 
> The newly introduced BPF_F_ADJ_ROOM_ENCAP_MASK is never used in a
> validation expression. Its only consumer is the composition of
> BPF_F_ADJ_ROOM_MASK. This is still true at the tip of the series.
> 
> The commit body itself only claims refactoring of bpf_skb_net_shrink()
> and bpf_skb_adjust_room(), so the subject, body and diff disagree.
> 
> Could "and encap validation" be dropped from the subject (e.g. "bpf:
> refactor bpf_skb_adjust_room() flag masks"), or should bpf_skb_net_grow()'s
> encap checks be converted to the new mask in this patch?

In my view the suggested subject change is not worth a new series as
i) the current subject is not blatantly misleading.
ii) this patch does touch the ENCAP related masks