Fix map creation failure when a BPF have a data section on older
kernel. (< 5.2)
If the BPF uses that section, relocation will fail accordingly and
report an error.
Remove mem::forget::<HashMap>() calls in tests which fail to compile when
HashMap is provided by hashbrown:
info: running `cargo check --all-targets --no-default-features` on aya-obj (11/23)
Checking aya-obj v0.1.0 (/home/tamird/src/aya/aya-obj)
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:594:21
|
578 | let map = fake_legacy_map(1);
| --- binding `map` declared here
579 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
594 | mem::forget(map);
| ^^^ move out of `map` occurs here
595 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:655:21
|
632 | let map_1 = fake_legacy_map(1);
| ----- binding `map_1` declared here
...
635 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
655 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
656 | mem::forget(map_2);
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:656:21
|
633 | let map_2 = fake_legacy_map(2);
| ----- binding `map_2` declared here
...
636 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
656 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:694:21
|
678 | let map = fake_btf_map(1);
| --- binding `map` declared here
679 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
694 | mem::forget(map);
| ^^^ move out of `map` occurs here
695 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:755:21
|
732 | let map_1 = fake_btf_map(1);
| ----- binding `map_1` declared here
...
735 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
755 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
756 | mem::forget(map_2);
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:756:21
|
733 | let map_2 = fake_btf_map(2);
| ----- binding `map_2` declared here
...
736 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
756 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
For more information about this error, try `rustc --explain E0505`.
error: could not compile `aya-obj` due to 6 previous errors
warning: build failed, waiting for other jobs to finish...
error: process didn't exit successfully: `/home/tamird/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo check --all-targets --manifest-path aya-obj/Cargo.toml --no-default-features` (exit status: 101)
This fixes `cargo build --all-features` by sidestepping the feature
unification problem described in The Cargo Book[0].
Add `cargo hack --feature-powerset` to CI to enforce that this doesn't
regress (and that all combinations of features work).
Since error_in_core is nightly-only, use core-error and a fake std
module to allow aya-obj to build without std on stable.
[0] https://doc.rust-lang.org/cargo/reference/features.html#feature-unification
This fix the following issues:
- Previously the DATASEC name wasn't sanitized resulting on "Invalid
name" returned by old kernels.
- The newly created BTF struct had a size of 0 making old kernels refuse
it.
This was tested on Debian 10 with kernel 4.19.0-21.
Clearly split the code between `.maps`, `maps` and data maps (bss, data,
rodata). Sprinkle comments.
Remove MapKind which was effectively only needed since we used to have
one variant - BpfSectionKind::Data - to represent all data maps. Instead
add explicit BpfSectionKind::{Data, Rodata, Bss} variants and match on
those when we initialize maps.
Files changed:
M aya-obj/src/generated/btf_internal_bindings.rs
M aya-obj/src/generated/linux_bindings_aarch64.rs
M aya-obj/src/generated/linux_bindings_armv7.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
This adds support for loading XDP programs that are multi-buffer
capable, which is signalled using the xdp.frags section name. When this
is set, we should set the BPF_F_XDP_HAS_FRAGS flag when loading the
program into the kernel.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Include all new map types which were included in the last libbpf update
(5d13fd5aca).
Fixes: cb28533e2f ("aya-obj: Update `BPF_MAP_TYPE_CGROUP_STORAGE` name to `BPF_MAP_TYPE_CGRP_STORAGE`")
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Files changed:
M aya-obj/src/generated/linux_bindings_aarch64.rs
M aya-obj/src/generated/linux_bindings_armv7.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/aarch64/helpers.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/helpers.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/helpers.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/helpers.rs
- Set the version number of `aya-obj` to `0.1.0`.
- Update the description of the `aya-obj` crate.
- Add a section in README and rustdoc warning about the unstable API.
This commit adds documentation on how program names are parsed from
section names, as is used by `aya_obj::Object.programs` as HashMap keys,
and updates the examples into using program names.
The crate has few libstd dependencies. Since it should be platform-
independent in principle, making it no_std like the object crate would
seem reasonable.
However, the feature `error_in_core` is not yet stabilized, and the
thiserror crate currently offers no no_std support. When the feature
no_std is selected, we enable the `error_in_core` feature, switch to
thiserror-core and replace the HashMap with the one in hashbrown.
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: #473
Aya::obj depends on bindgen generated files, and we start
by migrating bindgen generated files.
This commit adds the new aya-obj crate to the workplace
and migrates generated files into the crate. We use core
instead of std in an effort to make the final crate no_std.
Bindgen was run against libbpf v1.0.1.
Refs: #473