-
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
tracee-ebpf: simplify saving to buf #1016
tracee-ebpf: simplify saving to buf #1016
Conversation
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.
Do I understand correctly that you're calculating the index of the string buffer when you originally create it, and then use it when accessing the buffer, instead of recalculating on each access?
@@ -1462,6 +1462,11 @@ static __always_inline int save_path_to_str_buf(buf_t *string_p, const struct pa | |||
unsigned int off; | |||
int sz; | |||
|
|||
// Get per-cpu string buffer |
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.
BPF programs can't be preempted and moved to a different CPU, right?
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.
Right
I only moved the logic into a new function, nothing changed with the string indexes. The string buffer is used as a temporary buffer to store the string while it is being created. buf_off tells where the string starts in the buffer (the string doesn't start from offset 0, as the path components are added in a reverse order). So, instead of returning buf_off and then using it as an index to the string buffer when using save_str_to_buf, I now return the address of string_p[buf_off], which gives the same effect |
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!
No description provided.