-
Notifications
You must be signed in to change notification settings - Fork 165
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(userspace/libsinsp): multiple fixes related to rawargs. #2130
Conversation
/milestone 0.19.0 |
a351bb7
to
d8c26f3
Compare
@@ -139,6 +139,8 @@ Json::Value sinsp_filter_check::rawval_to_json(uint8_t* rawval, | |||
|
|||
case PT_L4PROTO: // This can be resolved in the future | |||
case PT_UINT8: | |||
case PT_FLAGS8: |
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.
We did not support FLAGS
and ENUMFLAGS
in rawval_to_{json,string}.
if(print_format == PF_OCT) { | ||
prfmt = (char*)"%" PRIo8; | ||
} else if(print_format == PF_DEC || print_format == PF_ID) { | ||
prfmt = (char*)"%" PRIu8; | ||
} else if(print_format == PF_HEX) { | ||
prfmt = (char*)"%" PRIu8; | ||
prfmt = (char*)"%" PRIX8; |
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.
Fix print format for 8,16,32bits types for PF_HEX.
@@ -1192,7 +1194,7 @@ uint8_t* sinsp_filter_check_event::extract_single(sinsp_evt* evt, | |||
m_val.u16 = evt->get_cpuid(); | |||
RETURN_EXTRACT_VAR(m_val.u16); | |||
case TYPE_ARGRAW: | |||
return extract_argraw(evt, len, m_arginfo->name); | |||
return extract_argraw(evt, len, m_argname.c_str()); |
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.
Use m_argname
here that is exactly the same as m_arginfo->name
.
d8c26f3
to
a02a0ec
Compare
// to allow `eval_filter` expressions to be properly compiled. | ||
// Note: even if they'll be overridden, | ||
// it is safe to guess that eg: `size` param will always be a numeric type. | ||
// Of course if we had a `size` param that is string, it would be troublesome. | ||
m_customfield.m_type = m_arginfo->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.
Per-comment: store the first one found to allow proper compilation of filters on this field; this works fine unless we have an event param, eg: flags
, that in an event is int
type, and in another is string
type.
That's not the case right now.
|
||
if(pi != NULL) { | ||
m_arginfo = pi->get_info(); | ||
m_customfield.m_type = m_arginfo->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.
Store correct field type and print format from the being-extracted event.
a02a0ec
to
e4543d0
Compare
Perf diff from master - unit tests
Heap diff from master - unit tests
Heap diff from master - scap file
Benchmarks diff from master
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2130 +/- ##
==========================================
+ Coverage 74.46% 74.56% +0.10%
==========================================
Files 254 254
Lines 33333 33369 +36
Branches 5733 5720 -13
==========================================
+ Hits 24820 24881 +61
+ Misses 8509 8485 -24
+ Partials 4 3 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
evt = add_event_advance_ts(increasing_ts(), 1, PPME_SYSCALL_BRK_4_E, 1, addr); | ||
// UINT64_MAX is FFFFFFFFFFFFFFFF | ||
ASSERT_EQ(get_field_as_string(evt, "evt.rawarg.addr"), "FFFFFFFFFFFFFFFF"); | ||
ASSERT_ANY_THROW(eval_filter(evt, "evt.rawarg.addr > 0")); // PT_SOCKADDR is not comparable |
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.
This issue is still present: even f the addr
arg for brk
event is an uint64_t, the initial filter arginfo is set to the first addr
found in the event_table
, ie: PPME_SOCKET_BIND_X
that has a PT_SOCKADDR
addr argument.
PT_SOCKADDR
is not a comparable type (see filter_compare.cpp flt_is_comparable
function) therefore we are not able to compile any filter against it.
NOTE: this was an issue already present on master.
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.
yep not sure what to do here, one thing could be to rename some parameters to avoid the issue. We should reach a point where params with the same name have the same type, but yes this would be a breaking change...
/hold |
// it is safe to guess that eg: `size` param will always be a numeric type. | ||
// Of course if we had a `size` param that is string, it would be troublesome. |
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.
i would just remove this since we have already found a corner case (addr
). Maybe we could list here all the cases we are aware of, for example for now addr
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.
Yep i am afraid that we forgot once again 😆
evt = add_event_advance_ts(increasing_ts(), 1, PPME_SYSCALL_BRK_4_E, 1, addr); | ||
// UINT64_MAX is FFFFFFFFFFFFFFFF | ||
ASSERT_EQ(get_field_as_string(evt, "evt.rawarg.addr"), "FFFFFFFFFFFFFFFF"); | ||
ASSERT_ANY_THROW(eval_filter(evt, "evt.rawarg.addr > 0")); // PT_SOCKADDR is not comparable |
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.
yep not sure what to do here, one thing could be to rename some parameters to avoid the issue. We should reach a point where params with the same name have the same type, but yes this would be a breaking change...
Firstly, properly refresh m_arginfo and m_customfield type and print format given current event while extracting rawarg values. Secondly, propelry support PT_FLAGS, PT_ENUMFLAGS, PT_GID and PT_UID types in `rawval_to_json` and `rawval_to_string`. Lastly, honor PF_HEX print format for 8,16,32bits types. Signed-off-by: Federico Di Pierro <[email protected]> Co-authored-by: Andrea Terzolo <[email protected]>
e4543d0
to
d0c002f
Compare
Rebased on top of latest master to make use of new cncf provided arm64 runners. |
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/unhold |
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area libsinsp
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Firstly, properly refresh m_arginfo and m_customfield type and print format given current event while extracting rawarg values.
Secondly, properly support PT_FLAGS, PT_ENUMFLAGS, PT_UID and PT_GID types in
rawval_to_json
andrawval_to_string
.Lastly, honor PF_HEX print format for 8,16,32bits types.
Also, added a test.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
These issues were found by @Andreagit97 while working on the syscall enter dropping (#2068)
Does this PR introduce a user-facing change?: