variable: return native Go pointers to bpf map memory#1607
Merged
ti-mo merged 2 commits intocilium:mainfrom May 5, 2025
Merged
variable: return native Go pointers to bpf map memory#1607ti-mo merged 2 commits intocilium:mainfrom
ti-mo merged 2 commits intocilium:mainfrom
Conversation
2 tasks
ti-mo
changed the title
ti-mo
force-pushed
the
tb/atomic-memory
branch
from
1c12429 to
ea5f31d
Compare
ti-mo
changed the title
ti-mo
force-pushed
the
tb/atomic-memory
branch
3 times, most recently
from
2d43b45 to
821aa80
Compare
mejedi
reviewed
Mar 4, 2025
Contributor
Author
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
Contributor
lmb
left a comment
lmb
left a comment
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.
ti-mo
force-pushed
the
tb/atomic-memory
branch
3 times, most recently
from
17713b9 to
534173e
Compare
ti-mo
force-pushed
the
tb/atomic-memory
branch
3 times, most recently
from
e31d8af to
3869345
Compare
Signed-off-by: Timo Beckers <[email protected]>
Signed-off-by: Timo Beckers <[email protected]>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.