libbpf-rs is unable to load eBPF programs on older kernel versions #1151
Comments
|
On old kernel that do not support memory-mapped global variable maps, libbpf will just avoid doing mmap. So libbpf-rs doesn't seem to handle this condition. Not sure what would make the most sense, I'd rather wait for Daniel (libbpf-rs maintainer) to come back to decide on best ways to handle this. |
|
Do we have any updates on this issue? |
|
I suspect given this behavior we may have to make each |
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
Commit 27dfe16 "libbpf-cargo: Don't provide kconfig data access after "open"" worked around the fact that the kconfig data member may not be present whenever. As it turns out, there is no guarantee that any of the data members are available as memory mapped data: on older kernels that "do not support memory-mapped global variable maps, libbpf will just avoid doing mmap" [0]. Revert this special sauce work around, as that means it's basically unnecessary now and we have to come up with a generic solution instead. This reverts commit 27dfe16. [0]: libbpf#1151 (comment) Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
As discussed in libbpf#1151, libbpf may not provide access to any of the data sec members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: libbpf#1151 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
As discussed in libbpf#1151, libbpf may not provide direct memory map access to any of the BPF map members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: libbpf#1151 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
As discussed in libbpf#1151, libbpf may not provide direct memory map access to any of the BPF map members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: libbpf#1151 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
As discussed in libbpf#1151, libbpf may not provide direct memory map access to any of the BPF map members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: libbpf#1151 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
to d-e-s-o/libbpf-rs
that referenced
this issue
May 5, 2025
As discussed in libbpf#1151, libbpf may not provide direct memory map access to any of the BPF map members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: libbpf#1151 Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
that referenced
this issue
May 7, 2025
Commit 27dfe16 "libbpf-cargo: Don't provide kconfig data access after "open"" worked around the fact that the kconfig data member may not be present whenever. As it turns out, there is no guarantee that any of the data members are available as memory mapped data: on older kernels that "do not support memory-mapped global variable maps, libbpf will just avoid doing mmap" [0]. Revert this special sauce work around, as that means it's basically unnecessary now and we have to come up with a generic solution instead. This reverts commit 27dfe16. [0]: #1151 (comment) Signed-off-by: Daniel Müller <[email protected]>
d-e-s-o
added a commit
that referenced
this issue
May 7, 2025
As discussed in #1151, libbpf may not provide direct memory map access to any of the BPF map members if the kernel does not support memory-mapped global variable maps. To that end, make them all optional. Closes: #1151 Signed-off-by: Daniel Müller <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Kernel version: 5.4.0-1125-aws
Distro: Ubuntu 18.04.6 LTS
After bumping our libbpf-rs version from 0.21.2->0.24.8, we ran into the following error when trying to run our program on a system running kernel 5.4
The error is being thrown during the
newfunction of the auto generatedOpenXXXXMapscode in*.skel.rs. This error does not occur when we run our program but with libbpf-rs version 0.21.2.How to reproduce:
Attempting to run the sample
capableon a new EC2 instance with the same kernel/distro version yields the same error but forrodata.The text was updated successfully, but these errors were encountered: