Re: [PATCH bpf-next v4 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Medium] The newly named `enum bpf_adj_room_flags` will not be emitted into the kernel's BTF, rendering the intended CO-RE lookups non-functional.
--

commit d9be60117de7ebbae2642c8a29e31a5aa11ff502
Author: Nick Hudson <nhudson@akamai.com>

bpf: name the enum for BPF_FUNC_skb_adjust_room flags

This commit names the previously anonymous enum for BPF_FUNC_skb_adjust_room
flags to bpf_adj_room_flags. The stated goal is to enable CO-RE lookups in
BPF programs.

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index c8d400b7680a8..bc4b25eb72ce5 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -6209,7 +6209,7 @@ enum {
>  };
>  
>  /* BPF_FUNC_skb_adjust_room flags. */
> -enum {
> +enum bpf_adj_room_flags {

Since this enum is only declared in the UAPI header and never actually used as
a variable, parameter, or struct field type in the kernel C code, will the
compiler generate DWARF debug information for it?

If it is omitted from the DWARF info, pahole will not emit it into the
vmlinux BTF. This causes libbpf CO-RE checks for these values to silently
evaluate to false regardless of the kernel version, which seems to defeat the
purpose of this patch.

Does the kernel need to explicitly force the emission of this type into the
target BTF, for example by using BTF_TYPE_EMIT(enum bpf_adj_room_flags) in a
compiled C file?

>  	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),

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416075514.927101-1-nhudson@akamai.com?part=1