Use pinned Linux version

[d-e-s-o]

We really shouldn't be using the moving target that is "the latest" Linux kernel version: just changing a config flag would introduce a bunch of completely unrelated changes, including potentially wrecking a config if certain high profile options were to be renamed.

Fixate the Linux kernel version so that we have full control over what we use. Stick to 6.18, which is what commit 991dd4b ("Update vmlinux.h headers from Linux 6.14 to 6.18") bumped us to.

[theihor]

The reasoning for downloading the latest mainline was that we ran the scripts "manually" (triggering CI), usually with the intention to update vmlinux.h to the latest. But formalizing this in explicit diff/pr makes sense too.

I'm thinking, we could fully automate this thing with a bit more yaml:

• check for new mainline once in a while
• if changed, generate vmlinux.h and create PR updating them
• (maybe even) if tests are green, auto-merge

Basically, instead of using up-to-dateness workflow to notify us, the vmlinux.h gets auto-updated unless there is a problem.

Thoughts?

[javierhonduco]

Love this!! Just checked that it the header file for the pinned kernel version compiles without warnings, unlike the latest version which fails with https://lists.openwall.net/linux-kernel/2025/11/13/1044

(nix:nix-shell-env) [fhonduvillac@fedora lightswitch]$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   src/bpf/vmlinux.h
	modified:   src/bpf/vmlinux_arm64.h
	modified:   src/bpf/vmlinux_x86.h

no changes added to commit (use "git add" and/or "git commit -a")
(nix:nix-shell-env) [fhonduvillac@fedora lightswitch]$ cargo b
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
(nix:nix-shell-env) [fhonduvillac@fedora lightswitch]$

[d-e-s-o]

But formalizing this in explicit diff/pr makes sense too.

I'm thinking, we could fully automate this thing with a bit more yaml:

• check for new mainline once in a while
• if changed, generate vmlinux.h and create PR updating them
• (maybe even) if tests are green, auto-merge

Yeah, these suggestions make sense. I think we can parametrize workflow_dispath and then fetch latest, with something like that:

  workflow_dispatch:
    inputs:
      environment:
        description: "Target environment"
        required: true
        default: "v6.18"
        type: choice
        options:
          - "lts"

Or so.

Then we could have a cron job that runs that logic every week or so. Will take a look in the future.