gentypes: Generate new types in the incoming v7.0 kernel

[Asphaltt]

A new tracing attach type, fsession, was recently introduced in the kernel (kernel-patches/bpf@2d419c4).

I’m planning to add fsession support to bpfsnoop.

Before doing so, I wanted to ask about the expected workflow for handling newly added BPF types (e.g. attach types, flags, commands, map types) in this repository. Is there a preferred way to track and incorporate such kernel additions into internal/sys/types.go?

While looking into this, I also noticed that several other BPF-related constants have been added to the kernel over time but are not yet reflected here. For reference, the following diff shows some of these additions:

diff --git a/internal/sys/types.go b/internal/sys/types.go
index 8826c62..0a769d2 100644
--- a/internal/sys/types.go
+++ b/internal/sys/types.go
@@ -44,9 +44,11 @@ const (
        BPF_F_ADJ_ROOM_ENCAP_L4_UDP                = 16
        BPF_F_ADJ_ROOM_FIXED_GSO                   = 1
        BPF_F_ADJ_ROOM_NO_CSUM_RESET               = 32
+       BPF_F_ALL_CPUS                             = 16
        BPF_F_BPRM_SECUREEXEC                      = 1
        BPF_F_BROADCAST                            = 8
        BPF_F_CLONE                                = 512
+       BPF_F_CPU                                  = 8
        BPF_F_CTXLEN_MASK                          = 4503595332403200
        BPF_F_CURRENT_CPU                          = 4294967295
        BPF_F_CURRENT_NETNS                        = 18446744073709551615
@@ -77,6 +79,7 @@ const (
        BPF_F_PEER                                 = 131072
        BPF_F_PRESERVE_ELEMS                       = 2048
        BPF_F_PSEUDO_HDR                           = 16
+       BPF_F_RB_OVERWRITE                         = 524288
        BPF_F_RDONLY                               = 8
        BPF_F_RDONLY_PROG                          = 128
        BPF_F_RECOMPUTE_CSUM                       = 1
@@ -109,6 +112,7 @@ const (
        BPF_RB_CONS_POS                            = 2
        BPF_RB_FORCE_WAKEUP                        = 2
        BPF_RB_NO_WAKEUP                           = 1
+       BPF_RB_OVERWRITE_POS                       = 4
        BPF_RB_PROD_POS                            = 3
        BPF_RB_RING_SIZE                           = 1
        BPF_REG_0                                  = 0
@@ -130,6 +134,7 @@ const (
        BPF_SKB_CLOCK_TAI                          = 2
        BPF_SKB_TSTAMP_DELIVERY_MONO               = 1
        BPF_SKB_TSTAMP_UNSPEC                      = 0
+       BPF_SKEL_KERNEL                            = 1
        BPF_SK_LOOKUP_F_NO_REUSEPORT               = 2
        BPF_SK_LOOKUP_F_REPLACE                    = 1
        BPF_SK_STORAGE_GET_F_CREATE                = 1
@@ -253,7 +258,8 @@ const (
        BPF_NETKIT_PEER                    AttachType = 55
        BPF_TRACE_KPROBE_SESSION           AttachType = 56
        BPF_TRACE_UPROBE_SESSION           AttachType = 57
-       __MAX_BPF_ATTACH_TYPE              AttachType = 58
+       BPF_TRACE_FSESSION                 AttachType = 58
+       __MAX_BPF_ATTACH_TYPE              AttachType = 59
 )
 
 type Cmd uint32
@@ -298,7 +304,9 @@ const (
        BPF_PROG_BIND_MAP               Cmd = 35
        BPF_TOKEN_CREATE                Cmd = 36
        BPF_PROG_STREAM_READ_BY_FD      Cmd = 37
-       __MAX_BPF_CMD                   Cmd = 38
+       BPF_PROG_ASSOC_STRUCT_OPS       Cmd = 38
+       __MAX_BPF_CMD                   Cmd = 39
+       BPF_COMMON_ATTRS                Cmd = 65536
 )
 
 type FunctionId uint32
@@ -586,7 +594,8 @@ const (
        BPF_MAP_TYPE_USER_RINGBUF                     MapType = 31
        BPF_MAP_TYPE_CGRP_STORAGE                     MapType = 32
        BPF_MAP_TYPE_ARENA                            MapType = 33
-       __MAX_BPF_MAP_TYPE                            MapType = 34
+       BPF_MAP_TYPE_INSN_ARRAY                       MapType = 34
+       __MAX_BPF_MAP_TYPE                            MapType = 35
 )
 
 type ObjType uint32

I’d appreciate any guidance on whether these should be updated incrementally as needed, or if there’s a more systematic approach planned for keeping kernel and user-space definitions in sync.

[ti-mo]

Hi Leon,

On the one hand, you're mentioning gentypes in the discussion title, but on the other hand, you seem to wonder where the generated types come from, so I'm a little confused. 😛

See the go:generate statement in internal/sys/doc.go. It spits out sys/types.go based on what's in btf/testdata/vmlinux.btf.gz, which in turn is generated by scripts/update-kernel-deps.sh. This script reads CI_MAX_KERNEL_VERSION from the GH workflow and pulls that version from the test kernels managed in github.com/cilium/ci-kernels. Currently, the generated types should be up to date until kernel 6.18.

I also noticed that several other BPF-related constants have been added to the kernel over time but are not yet reflected here.

Fsession support was pulled into bpf-next on Jan 24th, claiming we're out-of-date is a bit of a stretch. 🙂 We'll pull in the new constants when they land in mainline, since we can't run CI on them before they do.

[Asphaltt]

so I'm a little confused.

Sorry about that.

We'll pull in the new constants when they land in mainline

Great, that makes sense.

The fsession attach type was co-developed by me and is expected to land in mainline in the future. Around the same time, the new map type BPF_MAP_TYPE_INSN_ARRAY, developed by Anton, is also expected to land in mainline.

It would be helpful if this eBPF library could stay closely aligned with mainline, since new constants and features are typically introduced alongside kernel releases. For example, the aforementioned BPF_COMMON_ATTRS is expected to be merged in the next merge window.

At the moment, I maintain a custom fork of the eBPF library to add fsession support, so there is no urgency to pull the new constants from the bpf-next tree into this library immediately.