Sashiko discussions
 help / color / mirror / Atom feed
* 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