-
Notifications
You must be signed in to change notification settings - Fork 96
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
Fix error message in BPFMap.Update #29
Fix error message in BPFMap.Update #29
Conversation
When trying to obtain an unsafe pointer to the value type, upon failure the code was incorrectly returning an error message which contained the type of the key, not the value. This patch fixes it so that the correct type is returned for the value in the error message. Additionally this commit contains a small refactor which uses a type switch rather than if-else statements for readability.
02df214
to
95a0f3d
Compare
@@ -442,21 +442,22 @@ func (b *BPFMap) GetMaxEntries() uint32 { | |||
|
|||
func GetUnsafePointer(data interface{}) (unsafe.Pointer, error) { | |||
var dataPtr unsafe.Pointer | |||
if k, isType := data.(int8); isType { | |||
switch k := data.(type) { |
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.
Nice!
I wasn't aware of this type switch option.
And now I'm asking myself - do we even need the switch-case?
All the cases do the same thing - dataPtr = unsafe.Pointer(&k)
except the byte slice...
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.
Ok, after reading about type switches I understand that we must do it this way so that k will have the correct type asserted.
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.
(Editing to remove my incorrect statement :) )
However I'm curious why this function is so restrictive in the first place. I've actually spoken with @grantseltzer offline about this and plan on hacking on this further in order to allow more arbitrary types, if possible.
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.
When I wrote this code, I tried to find a generic method to get a pointer to the concrete type so I can pass it to libbpf, but couldn't find any. So I just coded the types that were needed for tracee, which I guess are the most common ones.
I'll be happy to change this code to something more generic if there is a simple way to do that
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.
Ack, makes sense!
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
When trying to obtain an unsafe pointer to the value type, upon failure
the code was incorrectly returning an error message which contained the
type of the key, not the value. This patch fixes it so that the correct
type is returned for the value in the error message.
Additionally this commit contains a small refactor which uses a type
switch rather than if-else statements for readability.