This was mistakenly comparing the exit code of the syscall, which is
always -1 and not the corresponding error-code. Added unit tests to
ensure we don't regress.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
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>
The comment says that `.derive_debug` was needed as
a workaround for https://github.com/rust-lang/rust-bindgen/issues/2083.
This issue is now closed, and aya-tool compiles without derive_debug.
Additionally, update bindgen dependency to 1.64.
Signed-off-by: Dmitry Savintsev <dsavints@gmail.com>
This commit adds from_pin() which allows the creation of a Program
from a path on bpffs. This is useful to be able to call `attach` or
other APIs for programs that are already loaded to the kernel.
This differs from #444 since it implements this on the concrete program
type, not the Program enum, allowing the user to pass in any additional
context that isn't available from bpf_prog_info.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Fix a bug which was resulting in `ENOTSUPP` following
the `BPF_MAP_CREATE` Syscall. This fix was initially
found by libbpf maintainers in:
https://github.com/libbpf/libbpf/issues/355.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
Allow to define programs as public functions (even in library crates)
and then import them.
For example, we can have library crate with `libfoo/src/lib.rs`
containing:
```rust
pub fn my_xdp_program(ctx: XdpContext) -> u32 {
xdp_action::XDP_PASS
}
```
And then a binary importing it:
```rust
pub use libfoo::my_xdp_program;
```
This way, commonly used eBPF programs can be distributed as lib crates.
Tested with: https://github.com/vadorovsky/aya-examples/tree/main/pub-progs
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
- Rename `new_tc_link` to `attached`
- Simplified example for `attached`
The following was not requested in reviews:
- Moved example from `SchedClassifierLink` tor
`SchedClassifierLink::attached' since we're only showing an
example of that one method
Signed-off-by: Andre Fredette <afredette@redhat.com>
This is the proposed solution for Step 2 of issue #414
“For cases where you have done program.take_link() to manage
ownership of TcLink we need an API similar to PinnedLink::from_pin
that can reconstruct a TcLink”
As long as a user application continues to run after executing
`take_link()`, the `SchedClassifierLink` returned can be used to
detach the program. However, if we want to handle cases where the
application exits or crashes, we need a way to save and reconstruct
the link, and to do that, we also need to know the information
required for the reconstruction -- namely, the `interface`,
`attach_type`, `priority`, and `handle`. The user knows the first
two because they are required to execute `attach()` in the first
place; however, the user will not know the others if they let the
system choose them.
This pr solves the problems by adding an `impl` for
`SchedClassifierLink` with an accessor for `tc_options` and a `new()`
function.
Signed-off-by: Andre Fredette <afredette@redhat.com>
Dave Tucker
Alessandro Decina
vadorovsky
Dmitry Savintsev
Andrew Stoycos
Andre Fredette
dependabot[bot]
banditopazzo
Andre Fredette