variable: return native Go pointers to bpf map memory #1607
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
1c12429 to
ea5f31d
Compare
2d43b45 to
821aa80
Compare
mejedi
reviewed
Mar 4, 2025
I think the most pressing use case is atomics, which is currently not supported at all. Array variables currently work through Get() and Set(), but there's always a marshaling cost. Also, simply having the convenience of manipulating BPF variables like they are Go variables is nice. |
lmb
reviewed
Mar 17, 2025
lmb
reviewed
Apr 2, 2025
There was a problem hiding this comment.
Thanks for adding all those tests, they look excellent to me! Left one thought around how to enable / disable this, feel free to deal with that as you wish. I have concerns around what types should be allowed, where I'd appreciate it if we can be even more conservative for a start.
17713b9 to
534173e
Compare
e31d8af to
3869345
Compare
Signed-off-by: Timo Beckers <timo@isovalent.com>
Signed-off-by: Timo Beckers <timo@isovalent.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pending the proposal in golang/go#70224, here's the current API proposal for returning Go pointers to 'off-heap' bpf map memory:
We need a bit of help from the Go runtime to manage the lifecycle of the underlying memory mapping. Currently, this mmaps over a piece of Go heap to allow the GC to track pointers into the bpf map memory, obviating the need for tying the mmap's lifetime to an
ebpf.Memory. Instead, any Go pointers into the mmap will keep it alive, removing the risk of use-after-free.Clearly, this involves some dark arts, so we're not comfortable pushing this on users since
Collection.Variablesis populated by default. Any change in the runtime or allocator may break this, and the fallout means Go programs segfaulting without any hint as to why, which is not acceptable.--- Edit ---
Since the
runtime.AddManualMemoryCleanupproposal may take a while to implement, land and ship in a Go version we target, I've revived the patch set and put the heap-mapping behaviour behindCollectionOptions.UnsafeVariableExperiment.MemoryPointeris yet unexported, sinceMap.Memory()is typically called directly by the user and we'd need to store the feature flag in *Map, which doesn't feel ideal.Alternatively, we could go for an env feature flag instead of CollectionOptions (
EBPFUNSAFEVARIABLES=true?), which would allow us to export MemoryPointer and transparantly switch between implementations.