-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aya: skip map creation and relocation for maps that should be ignored #968
base: main
Are you sure you want to change the base?
aya: skip map creation and relocation for maps that should be ignored #968
Conversation
This makes it possible to have bytecode with unsupported map types such as BPF_MAP_TYPE_RINGBUF on a target kernel that doesn't have that map type
…a (removed by mistake)
❌ Deploy Preview for aya-rs-docs failed.Built without sensitive environment variables
|
Perhaps this should be scoped to only kernel-userspace data streaming ( |
Does this actually work, if in the ringbuf==1 case you access the RINGBUF map, and then in the else you access the PERFBUF map? Because if you skip relocating it, I would have expected the verifier to complain that the map fd is not valid. If this does work, can you add an integration test please? |
I tend to think the opposite: the current mechanism is too restrictive and it should be more generic. Right now you can ignore loading a map type, but what if I want to ignore loading only an instance of a map type (because eg, a bit of functionality is disabled, and I want to save the memory?). I'm thinking it's probably better to have something like |
It actually started out like that, with the name rather than the type. I can revert it back to that or add a new function that filters by name and keep the one by id also? I see no reason why both can't exist |
…hat does the same by name. Fixed renaming and added the new 3rd argument to relocate_maps() for rbpf test case
This PR has a clippy allow for |
…properly working
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice work! See comments
Thanks for the feedback. I left a comment to one of your review comments. The rest is straight forward. I'll see when I have time to fix it |
@martinsoees, this pull request is now in conflict and requires a rebase. |
- Removed 'ignore_map_by_type' since 'ignore_map_by_name' makes more sense
- Removed 'ignore_map_by_type' since 'ignore_map_by_name' makes more sense
The 'ignore_map_by_type' function has been removed. Also renamed test function and simplified the relocation builder since 'by_name' is the only option now
@@ -232,6 +250,8 @@ fn relocate_maps<'a, I: Iterator<Item = &'a Relocation>>( | |||
); | |||
debug_assert_eq!(map.symbol_index().unwrap(), rel.symbol_index); | |||
m | |||
} else if ignored_by_section.contains(§ion_index) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is correct, it's just not getting exercised by the test because we do have symbols. We switched to putting all maps in the same section (like libbpf does), so I think that this would skip all the maps?
@martinsoees, this pull request is now in conflict and requires a rebase. |
Allows programs containing unsupported maps for the current
kernel to be loaded by skipping map creation and relocation before loading.
This is useful when you have a single program containing e.g. a
RingBuf
and a
PerfEventArray
and you decide from user space which one to usebefore loading the bytecode by checking if the kernel you are running
on has support for e.g.
RingBuf
.That way you can use the same eBPF bytecode across multiple kernels
regardless of the kernel has support for it or not.
Can be used with
.set_global()
to signal if the map is supporteduntil support for
bpf_core_enum_value_exists
.Example user space code:
Example eBPF bytecode:
This change is