Make the xz2 dependency optional to allow building without a C cross
compiler. This allows clippy.sh to be used on e.g. macOS more easily:
```
./clippy.sh --target x86_64-unknown-linux-gnu --exclude-features xz2
```
This removes octorust which takes absolutely ages to compile and also
requires native TLS libraries which in turn require a C toolchain. The
latter is a pain when cross compiling from macOS.
This reverts commit cc2da4a2a4.
The binding for BPF_ADD was missing from codegen.
Use BPF_.* to capture all of these to avoid missing bindings in future.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
In aarch64, with kernel 5.5, my programs that use `bpf_probe_read_user`
don't work successfully because `aya` is mistakenly re-writting it
`bpf_probe_read` because it falsely detects that the kernel doesn't
support `bpf_probe_read_user`.
I hadn't updated my `aya` version in a while, but while updating it to
fix a separate issue (panics when parsing kernel versions of PVE
kernels) and running my test suite I saw tests failing on aarch64 5.5
kernels. A git bisect led me to this commit:
942ea51906 and further investigation in the
difference of the new and old assembly showed that the only difference
was subtracting 8 vs adding -8. When I put it back as adding 8 (but
without handwritten assembly) then things work as expected. Since it
used to be `BPF_ADD` and the commit that changed it was just about no
longer handwriting assembly without any reason for the switch to
`BPF_SUB` putting it back as `BPF_ADD` seems reasonable.
When using `BPF_SUB` 8, the handwritten program in this function
returns a permission error which is treated by this function as
`bpf_probe_read_kernel` not being supported when it is but for some
reason `BPF_SUB` is not. My guess is that it might be an early verifier
error but I am not 100% sure as I thought verifier errors are normally
`EINVAL` not `EPERM` but I have a vague memory of seeing `EPERM` in the
past for errors that happened very early in the verifier.
Fixes: #1233
At present, `aya_build` will always use `+nightly` to build the
eBPF kernel. This is problematic in environments such as CI, where
tools always need to be installed first. Installing the current
nightly Rust toolchain gives you a new toolchain every day. This
poisones caches and makes CI jobs non-deterministic.
Resolves: #1226
Working with aya in vscode will currently show a number of warnings
along the lines of:
```
found duplicate lang item `panic_impl`
the lang item is first defined in crate `std` (which `aya` depends on)
...
second definition in the local crate (`bpf_probe_read`)
```
This comes from feature unification.
integration-test requires the integration-common user feature, which
requires aya, which in turn brings in std.
For this same reason we avoid running clippy across the whole workspace.
We can avoid this issue by using the panic handler from the another
crate, which implements the same loop {} panic handler we use today.
It seems rustc is happy to conditionally link the panic handler
from an external crate without issuing warnings.
Therefore, we add our own crate - ebpf-panic - for this purpose.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
clippy complained that cfg_attr is applied to the macro invocation and
therefore will not be expanded. This was a false-positive, however
when playing with cargo expand I did notice that the cfg and cfg_attr
section weren't propagating as I would expect them to.
Adding a meta matcher to the impl_try_from_map macro allows us to
remove the need for AsyncPerfEventArray to be in a separate invocation
of the macro while also making sure that attributes do get propagated
to the generated functions.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Allow for a ProgramInfo to be converted into one of the program types
that we support. This allows for a user of Aya access to reattach,
pin or unload a program that was either, previously loaded, or was
loaded by another process.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
We have previously tried to import traits anonymously where possible but
enforcing this manually was hard.
Since Rust 1.83 clippy can now enforce this for us.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
The init module contains a small init system for running our integration
tests against a kernel. While we don't need a full-blown linux distro,
we do need some utilities.
Once such utility is `modprobe` which allows us to load kernel modules.
Rather than create a new module for this utility, I've instead
refactored `init` into `test-distro` which is a module that contains
multiple binaries.
The xtask code has been adjusted to ensure these binaries are inserted
into the correct places in our cpio archive, as well as bringing in the
kernel modules.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Rather than emitting a warning, assert the inverse of the condition when
the current kernel version is lower than required. This strengthens the
assertions made by our tests (provided we run them over kernel versions
before and after the listed version, which is not yet the case).
Limit of map names in eBPF is 16 bytes and they have to be NULL
terminated.
Before this change, long names were truncated to 16 bytes.
`MAP_WITH_LOOOONG_NAAAAAAAAME` would become `MAP_WITH_LOOOONG`, which
doesn't contain the NULL byte.
This change fixes that by truncating the name to 15 bytes, ensuring
that the 16th byte is NULL. `MAP_WITH_LOOOONG_NAAAAAAAAME` is truncated
to `MAP_WITH_LOOOON\0`.
In practice this will forbid unused dependencies because we run clippy
with `--deny warnings`.
Workspace lints is a nice place to ratchet up lints through the codebase
all at once and consistently.
Merging via comment isn't possible. We could merge this automatically on
green, however we'd prefer to use @dependabot merge or merge manually.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Tamir Duberstein
Dave Tucker
dependabot[bot]
dave-tucker
Andres
Michal Rostecki
Thomas Eizinger
tamird
x0rw
WANG Rui
Michal Rostecki
arctic-alpaca