Load cgroup_{device,sysctl}, flow_dissector, lirc_mode2, sk_msg,
sock_ops programs with their fixed expected attach types instead of
omitting them.
These program types already use the same constants when attaching.
Pass the kernel attach type into the shared loader from each typed
wrapper instead of storing a second mutable copy in `ProgramData`.
This removes the from_pin repair pattern, avoids stale shadow state, and
keeps attach paths driven by wrapper-owned typed attach metadata or
fixed constants.
Also simplify `{sk,cgroup}_skb` section parsing by representing all
variants as `ProgramSection::SkSkb { kind }` and
`ProgramSection::CgroupSkb { attach_type }` respectively, with the
attach type enums shared from aya-obj.
In some CI jobs, `cargo binstall` is convinced that bpf-linker is
already installed:
```
INFO resolve: bpf-linker v0.10.2 is already installed, use --force to override
```
When in reality, it's not there. Not sure what's the source of this
delusion, but let's just install it with `--force`.
Lower the template headings from level 1 to level 3 to satisfy the
`single-title` rule.
Disable `first-line-heading` as well, since the template intentionally
does not include a top-level document title.
I find them annoying and they're usually an obvious sign of LLM misuse.
Keep only the sections for additional questions from us, that follow
the summary.
Recommend *Fixes:* over *Closes:*, since it is the tag most commonly used
to close issues when a pull request is merged.
Remove the mention of *Relates To*, since it is not part of any of the
documented conventions. Clarify that non-closing issue references can be
included anywhere in the summary.
I have been inactive for quite some years since I left HarfangLab.
I do not have much interest in working on ancient kernels support or
feature parity with libbpf anymore.
I also want to note here that I am deeply concerned by the apparent
full support and acceptance of LLMs based tools.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Explains how Maintainers are selected and their responsibilities.
Explains the Pull Request review workflow.
Adds config for Mergify to enforce this workflow.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Currently, the API for calling kernel helpers on `TcContext`, `SkBuff`,
and `SockOpsContext` has inconsistent semantics. Methods like `store`,
`set_mark`, and `set_reply` require a mutable reference (`&mut self`),
while others that also modify the underlying state take a read-only
reference (`&self`).
This commit resolves the inconsistency reported in #1442 by changing
`store`, `set_mark`, and `set_reply` to take `&self` across `SkBuff`,
`SkBuffContext`, `TcContext`, and `SockOpsContext`.
The `cb_mut` method is intentionally left unchanged because returning
a mutable slice (`&mut [u32]`) from an immutable reference would
violate Rust's aliasing rules.
Fixes: #1442
Use `RUSTC_BOOTSTRAP` when deciding whether to pass `-Zbuild-std=core`.
This keeps eBPF builds working in environments without rustup where a
stable toolchain is used with bootstrap enabled to allow unstable
features. It also preserves `-1` as an explicit opt-out and accepts
crate-scoped bootstrap values.
Store ring buffer accounting in plain arrays instead of per-CPU arrays
and use atomic increments in the eBPF test program where concurrent
writers still share the counters.
Co-authored-by: Codex <noreply@openai.com>
Rename the eBPF global wrapper type to `Global` and update its
downstream uses and API snapshot so the public surface matches the new
name.
Co-authored-by: Codex <noreply@openai.com>
The depmod implementation used to scan for _symbols_ in the .modinfo
section containing "alias" in the name. That stopped working from kernel
6.17 and broke the smoke::modprobe test.
The aliases can be parsed from the .modinfo section itself, no need to
look at symbols at all.
Fixes integration tests on 6.17.
The netlink attribute buffer in TcRequest was only 64 bytes, which is
not enough when TC program names get close to the kernel's 256-byte
limit. This led to a misleading no space left error when attaching
programs with longer names.
Bump the buffer size so it can precisely fit all the netlink attributes
and the max-length name.
The helpers always return a signed 64-bit r0 value, but the JIT that
translates eBPF into native instructions differs by architecture. On
x86_64 the generated code writes the helper result into a 64-bit
register, so the CPU sign-extends negative errnos automatically. On
aarch64 the JIT frequently uses 32-bit operations (w0) when copying the
helper return and only zero-extends into the upper half of x0.
That results in broken errno codes on aarch64. For example, when a map
operation returns `-ENOENT`, which is supposed to be -2, the i64
representation yields something like `0x0000_0000_FFFF_FFFE`
(4294967294) instead of -2. In short: the ARM64 JIT doesn’t preserve the
sign in the upper half of the 64-bit register, and the error code has to
be cast to a 32-bit integer to make the sign visible.
This makes it awkward for users, because that behavior prevents simply
comparing helper error codes with constants like `libc::ENOENT` without
manual casts.
Given that the maximum error code limit `MAX_ERRNO` in the kernel is
4095, which fits in a 32-bit integer, coerce the error codes to be `i32`
and make all helpers return `Result<T, i32>`.
For most architectures just bpf_probe_read() works, but for those that
have overlapping memory address spaces, like UML, we must use the
specific helper.
Add a workflow-level concurrency group so PR workflows share a
`<workflow>-pr-<number>` group and GitHub cancels any in-progress run
when a new push arrives. Non-PR events fall back to the ref name, which
keeps push/cron runs isolated while still preventing multiple runs per
ref from piling up.
Tamir Duberstein
Kirill Lykov
dependabot[bot]
Amit Prasad
vad
Weixie Cui
Mary Guillemard
Dave Tucker
Aurélien DEROIDE
Afonso Quintas
Miroslav Hruz
Alessandro Decina
cong-or
tamird
Jamie Hill-Daniel
Gustavo Noronha Silva