From: Hannes Laimer <h.laimer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH proxmox v9 0/5] add proxmox-ebpf library
Date: Tue, 10 Nov 2026 14:50:00 +0100 [thread overview]
Message-ID: <20261110135005.2847847-1-h.laimer@proxmox.com> (raw)
proxmox-ebpf allows working with the BPF kernel state, it also handles
the loading of new programs and the pinning of them and the maps they
reference. It keeps track of map layouts currently loaded, and handles
the locking of concurrent updates to maps. And it offers an interface to
attach or detach programs to interfaces and fill the maps they
reference.
It places the pins in the following directory structure
```
/sys/fs/bpf/proxmox-ebpf/<subsystem>
links/
<schema-version>/
live/
<map_1>
prog/
<direction>
staging/
.. like live
```
This allows it to keep maps and programs that have a different schema
version strictly apart. With this we also make sure processes running
stale versions never interact with maps that they don't know the layout
of.
Program object files with the definitions of their maps are shipped as
a separate package, and this library expects them to be placed under
`/usr/lib/proxmox-ebpf/<subsystem>.bpf.o`. These shipped object files
have to have their schema version in the `.proxmox.schema` ELF section.
`/usr/lib/proxmox-ebpf/order` sets the order the programs of the
subsystems run in on an interface. A change to it only affects attaches.
Program and schema updates only swap the program of a link, so every
link keeps its place in the run-order.
All of this is covered in more detail in the doc sections of the two
modules.
v9, thanks a lot @Thomas and @Wolfgang!:
* move BPF object files into their own package, this means all the C
handling stuff left the lib. we now expect the object files under
`/usr/lib/proxmox-ebpf/<subsystem>.bpf.o`
* the order file is also shipped with the object files, and is expected
under `/usr/lib/proxmox-ebpf/order`
* fingerprint of the object binaries was also dropped, we now assume
the object files present on the host are current, so dependency
management of program versions is handled through debian packaging
* the schema version of a subsystem is now part of the object files
holding the programs and maps, it is in the `.proxmox.schema` ELF
section. the library only loads/interacts with object files that
have a matching schema-version, so on a map layout change both the
package shipping the object and the rust subsystem running it have to
bump their version
* use proxmox-sys's locking instead of polling
* improve docs
* check map type on load
v8:
* include map names and directions in program fingerprint in addition
to the object
* the repair after an interrupted replacement only moves links onto
programs the live set has, it does not detach links of a direction
the new build dropped before the new build is in, that broke a
replace that died while staging and then failed its fill
* include pkg version in order file, a newer build will seed the list
and merge the existing one in, an older build will merge its list
into the existing one. this solves the problem of whatever build is
run first seeds the order list at boot, basically making it random
* add missing context to err
v7:
* include rust pkg version next to fingerprint, so we can avoid
flip-flopping the loaded programs in case a worker stays around
during/after an upgrade
* differentiate between a link swap failing on open or on the swap
itself
* replacing the maps and clearing take the lock guard mutably, so a map
ref opened before cannot be written after the exchange, it would hit
the retired map
* the repair after an interrupted replacement also detaches the links
of a direction the update dropped, a retry that failed afterwards
left them attached
* add context to io errors
* merge a run order change, don't blindly replace, this covers cases
where something was added and reordered in one
v6:
* loop all links at the start of every replace, moving links to live/
is done one-by-one, so it can fail. a failed pass then has some links
still on staging/, this makes sure we don't delete state that may
still be attached. the kernel checks if it already exists on a swap,
so this is a no-op, and at worst an atomic swap for links that still
have staging/ attached
* only allow adding to the run order, at least for live updates.
removal or re-orders are applied on the next reboot
* enforce that map refs live as long as the lock they were taken under
* a pin that cannot be opened stays and fails the step instead of
being unlinked, which under a descriptor shortage detached a working
link
* the harness tests run a C program of their own against the shim
* move the crate into the proxmox workspace, the vendored vmlinux.h is
gone, the programs build against the UAPI headers of
proxmox-kernel-libc-dev with a versioned clang
v5:
* add a call that replaces the maps as a whole, it uses more space and
writes everything instead of only what changed, but leaves the old
content in place instead of a mix, in cases where the write fails
with ENOMEM. Subsystems choose which they need
* install/upgrade now also use this newly added replace path, this
simplifies the process and also closes a hole where attached programs
would read empty maps, shortly before they were filled after a schema
version bump
* the run order of the subsystems is written to
`/run/proxmox-ebpf/order` by a full apply and every attach places by
it, so a stale process running an older version attaches correctly
against subsystems added by a process running a newer version
* set correct permissions on `/run/..`
* a build whose schema is older than the pinned one no longer counts
its state as current, so its single steps back off as well
* add `interrupted()` on the lock guard, true when a replacement left
its staged set or an old schema directory behind, a full pass
replaces then
* an attach checks after attaching that the interface still has the
index of its pin, one recreated under the same name in between is
reported as gone
* a map missing from a pinned set is reported by name
v4, thanks @Stefan!:
* drop the generation counter, a change takes the apply lock before it
reads its input instead, so the lock order is the input order
* new, the links of different subsystems on an interface are now
ordered
* the tc link plumbing is its own commit ahead of the subsystem code
* subsystem programs are now a list of direction and name pairs
* add short note for why not proxmox-sys's locking
* improve tc error handling
* fix smaller spacing and code stuff
proxmox:
Hannes Laimer (5):
ebpf: init crate for the code shared by subsystems
ebpf: tc: add the link plumbing
ebpf: subsystem: add the shared tc program handling
ebpf: subsystem: place subsystem links in a fixed order
ebpf: debian: package the crate as a Rust library
Cargo.toml | 3 +
proxmox-ebpf/Cargo.toml | 22 +
proxmox-ebpf/debian/changelog | 5 +
proxmox-ebpf/debian/control | 50 ++
proxmox-ebpf/debian/copyright | 18 +
proxmox-ebpf/debian/debcargo.toml | 7 +
proxmox-ebpf/src/lib.rs | 7 +
proxmox-ebpf/src/subsystem.rs | 1280 +++++++++++++++++++++++++++++
proxmox-ebpf/src/tc.rs | 366 +++++++++
9 files changed, 1758 insertions(+)
create mode 100644 proxmox-ebpf/Cargo.toml
create mode 100644 proxmox-ebpf/debian/changelog
create mode 100644 proxmox-ebpf/debian/control
create mode 100644 proxmox-ebpf/debian/copyright
create mode 100644 proxmox-ebpf/debian/debcargo.toml
create mode 100644 proxmox-ebpf/src/lib.rs
create mode 100644 proxmox-ebpf/src/subsystem.rs
create mode 100644 proxmox-ebpf/src/tc.rs
Summary over all repositories:
9 files changed, 1758 insertions(+), 0 deletions(-)
--
Generated by murpp 0.12.0
next reply other threads:[~2026-11-10 13:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 13:50 Hannes Laimer [this message]
2026-11-10 13:50 ` [PATCH proxmox v9 1/5] ebpf: init crate for the code shared by subsystems Hannes Laimer
2026-11-10 13:50 ` [PATCH proxmox v9 2/5] ebpf: tc: add the link plumbing Hannes Laimer
2026-11-10 13:50 ` [PATCH proxmox v9 3/5] ebpf: subsystem: add the shared tc program handling Hannes Laimer
2026-11-10 13:50 ` [PATCH proxmox v9 4/5] ebpf: subsystem: place subsystem links in a fixed order Hannes Laimer
2026-11-10 13:50 ` [PATCH proxmox v9 5/5] ebpf: debian: package the crate as a Rust library Hannes Laimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261110135005.2847847-1-h.laimer@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox