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, bot+bpf-ci@kernel.org wrote:

quoted

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