variable: return native Go pointers to bpf map memory #1607
+535
−5
Conversation
This file contains 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
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
from
ea5f31d to
a03777e
Compare
Signed-off-by: Timo Beckers <[email protected]>
ti-mo
force-pushed
the
tb/atomic-memory
branch
from
a03777e to
2d43b45
Compare
Signed-off-by: Timo Beckers <[email protected]>
ti-mo
force-pushed
the
tb/atomic-memory
branch
from
2d43b45 to
821aa80
Compare
mejedi
reviewed
Mar 4, 2025
Comment on lines
+264
to
+269
| func VariablePointer[T any](v *Variable) (*T, error) { | ||
| if err := checkVariable[T](v); err != nil { | ||
| return nil, fmt.Errorf("variable pointer %s: %w", v.name, err) | ||
| } | ||
| return memoryPointer[T](v.mm, v.offset) | ||
| } |
There was a problem hiding this comment.
It doesn't look like it is possible to support slices within the same API, does it?
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.