Re: [PATCH v6 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags

bot+bpf-ci
2026-05-04T11:03:09Z

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 552bc5d9afbd..c021ed8d7b44 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -6211,7 +6211,7 @@ enum {
> };
>
> /* BPF_FUNC_skb_adjust_room flags. */
> -enum {
> +enum bpf_adj_room_flags {
> BPF_F_ADJ_ROOM_FIXED_GSO = (1ULL << 0),
> BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 = (1ULL << 1),
> BPF_F_ADJ_ROOM_ENCAP_L3_IPV6 = (1ULL << 2),

Martin KaFai Lau raised a concern in v2 about demonstrating the intended
CO-RE usage, specifically suggesting bpf_core_enum_value_exists():

https://lore.kernel.org/bpf/e5a2ad16-d2ac-4fa0-be41-162227257682@linux.dev/

He also requested that similar tests be added to test_tc_tunnel.c for the
new flags, as was done for earlier BPF_F_ADJ_ROOM_* flag additions.

While v3+ added selftests for decap GSO state validation, does the current
version include tests that explicitly demonstrate the CO-RE enum lookups for
bpf_adj_room_flags that motivated naming this enum?

> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 677be9a47347..ca35ed622ed5 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h

[ ... ]

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25314425016