* Re: [PATCH bpf-next v4 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags
[not found] ` <20260416100225.178D6C2BCAF@smtp.kernel.org>
@ 2026-04-16 14:18 ` Alexei Starovoitov
2026-04-17 11:44 ` Hudson, Nick
0 siblings, 1 reply; 2+ messages in thread
From: Alexei Starovoitov @ 2026-04-16 14:18 UTC (permalink / raw)
To: sashiko, Nick Hudson; +Cc: bpf
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 <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?
Nick,
take bots feedback with a grain of salt.
I suspect the bot is wrong here, but do you homework.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH bpf-next v4 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags
2026-04-16 14:18 ` [PATCH bpf-next v4 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags Alexei Starovoitov
@ 2026-04-17 11:44 ` Hudson, Nick
0 siblings, 0 replies; 2+ messages in thread
From: Hudson, Nick @ 2026-04-17 11:44 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: sashiko@lists.linux.dev, bpf@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]
> On Apr 16, 2026, at 3:18 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> 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 <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?
>
> Nick,
>
> take bots feedback with a grain of salt.
> I suspect the bot is wrong here, but do you homework.
>
Thanks.
I guess it depends on tools?
$ ./tools/bpf/bpftool/bpftool btf dump file vmlinux format c | grep -A 10 'enum bpf_adj_room_flags'
enum bpf_adj_room_flags {
BPF_F_ADJ_ROOM_FIXED_GSO = 1,
BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 = 2,
BPF_F_ADJ_ROOM_ENCAP_L3_IPV6 = 4,
BPF_F_ADJ_ROOM_ENCAP_L4_GRE = 8,
BPF_F_ADJ_ROOM_ENCAP_L4_UDP = 16,
BPF_F_ADJ_ROOM_NO_CSUM_RESET = 32,
BPF_F_ADJ_ROOM_ENCAP_L2_ETH = 64,
BPF_F_ADJ_ROOM_DECAP_L3_IPV4 = 128,
BPF_F_ADJ_ROOM_DECAP_L3_IPV6 = 256,
BPF_F_ADJ_ROOM_DECAP_L4_GRE = 512,
$
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3066 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-04-17 11:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260416075514.927101-2-nhudson@akamai.com>
[not found] ` <20260416100225.178D6C2BCAF@smtp.kernel.org>
2026-04-16 14:18 ` [PATCH bpf-next v4 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags Alexei Starovoitov
2026-04-17 11:44 ` Hudson, Nick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox