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

On Thu Apr 16, 2026 at 3:02 AM PDT, sashiko-bot wrote:
> 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 <[email protected]>
>
> 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?

Nick,

take bots feedback with a grain of salt.
I suspect the bot is wrong here, but do you homework.