-
Notifications
You must be signed in to change notification settings - Fork 392
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
tetragon: Add map ownership #2945
Conversation
9959201
to
e6b9e5b
Compare
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
e6b9e5b
to
9afe055
Compare
9afe055
to
f98ce9d
Compare
What are the possible use cases for it? restart ? or is it just to organize better?
Hmm others could be fine, or "non-owners"?, but those are certainly better than "users" ? or go with creators and users? ... |
so at the moment any user of the map will overwrite the pin file with its spec and max entries, it has also another aspect where you need all the users of the map to match the same spec having the owner and other user force the config duty only to owner and other users just use the map
hm, right.. maybe MapBuilder(..) for owner and MapUser(..) (instead MapOther) for other users.. with: also perhaps the MapOwner should be just bool.. iota is perhaps too much let's see.. thanks a lot for review |
This could be beneficial for accounting which sensor/progs/policies are responsible for BPF map memory use, cc @kkourt |
ddc3888
to
f5e02e3
Compare
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.
LGTM, minor suggestions with one log message that should be fixed. Thank you!
// Try to open the pinPath and if it exist use the previously | ||
// pinned map otherwise pin the map and next user will find | ||
// it here. | ||
if _, err := os.Stat(pinPath); err == nil { | ||
if _, err = os.Stat(pinPath); err == nil { | ||
m, err := ebpf.LoadPinnedMap(pinPath, nil) | ||
if err != nil { | ||
return nil, fmt.Errorf("loading pinned map from path '%s' failed: %w", pinPath, err) |
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.
Does it make sense to re-create here if we have create true?
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.
hm, so this leg is when there is already an existing pin and we check if the pin is compatible with what we want to create, if it is, we are done, if not, we remove the pin and create new one
pkg/sensors/program/map.go
Outdated
@@ -260,12 +261,23 @@ func LoadOrCreatePinnedMap(pinPath string, mapSpec *ebpf.MapSpec) (*ebpf.Map, er | |||
"map-name": mapSpec.Name, | |||
}).Warn("tetragon, incompatible map found: will delete and recreate") |
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.
Maybe this delete and recreate warn should be moved inside create true?
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.
good catch! will move, thanks
return m, nil | ||
} | ||
if create { | ||
return createPinnedMap(pinPath, mapSpec) |
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.
Could move this create just after the state(pinPath) failure , and have the rest outside of if , just for readability up to you
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.
hm, so it is already in the place after the stat failure.. not sure what you mean
Display pin path instead of the name, before: time="2024-09-21T21:09:35Z" level=info msg="map was unloaded" map=m1 pin=m1 time="2024-09-21T21:09:35Z" level=info msg="map was unloaded" map=m2 pin=m2 after: time="2024-09-21T21:10:34Z" level=info msg="map was unloaded" map=m1 pin=m1 time="2024-09-21T21:10:34Z" level=info msg="map was unloaded" map=m2 pin=policy/m2 Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding GetDefaultSensorsWithBase helper function to allow overloading of the base sensor. Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Introduce map owner field in Map object to state if the object is the real owner of the map. Basically the map object can be now either owner of the map or can just be its user. The ownership will matter when loading the map in following changes. Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Let's distinguish the map that 'owns' the pin and the 'user' map user that's just using it. The owner map gets to set (and overwrite if needed) pined map spec and its max entries setup. The user map just follows what is set in existing pinned map and fails if it's expecting anything else. Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding MapUser* interface to create map that you don't own. Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding test for pinned maps in multiple sensors just to cover common use case of using same maps cross sensors. Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding tests for 'user' maps to cover following scenarios: - user map gets properly created from pinned map - user map fails to be loaded if the pinned map is missing - user map fails to be loaded if the pinned map has different max entries setup - user map fails to be loaded if the pinned map is not compatible Signed-off-by: Jiri Olsa <jolsa@kernel.org>
f5e02e3
to
47b5d10
Compare
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.
🚀
// | ||
// Each map declares the ownership of the map. The map can be either | ||
// owner of the map (via MapBuilder* helpers) or as an user (MapUser* | ||
// helpers. |
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.
Thanks for adding the comments!
Adding the concept of owning map and splitting Map object to owners and others.
The idea is that the 'owned' Map object takes care of creating/overwriting the pin,
while the 'other' Map object is just a user, that can read/update map but can't create it.
I'm not really happy with the 'other' naming, so any ideas are welcome ;-)