fix(proctree): allow regular events to create proctree nodes #3498
Conversation
... preparing terrain for refactoring and for process tree processors.
| save_to_submit_buf(&p.event->args_buf, (void *) &child_start_time, sizeof(u64), 9); | ||
|
|
||
| // Process tree information (if needed). | ||
| if (p.config->options & OPT_FORK_PROCTREE) { |
There was a problem hiding this comment.
- Do we need this information now that @AlonZivony added the start time of all the three in every event?
- If you think we still need it, I don't think it needs to be gated with OPT_FORK_PROCTREE - this will cause inconsistencies in the event output between when the proc tree is enabled or not, so better to always send it as part of the event output
There was a problem hiding this comment.
We still need it.
My thought here is the following - if we want to have different arguments than the normal event, we should create a new event and submit it with the same first arguments and add on top of it the additional arguments (we do the same with magic_write I think).
We already have the concept of internal events, so I think it would be cleaner.
There was a problem hiding this comment.
Why do we still need it? Those are just extra fields - we shouldn't care about sending them since we don't remove any of the existing fields.
In the future, we are going to have process_fork user-friendly event anyway, so having more arguments here shouldn't be a problem
There was a problem hiding this comment.
We need the arguments because I don't pass the start times to the event, only to the decode step.
I don't think that increasing the size of the event drastically for an internal use and exposing all the confusing terms of up_parent and the likes is good for us. I believe that if this is only for an internal use, than it should be an internal event.
However, the question here is what do we do with the analyze mode?
The analyze mode will need this arguments, no?
There was a problem hiding this comment.
I don't think that increasing the size of the event drastically for an internal use and exposing all the confusing terms of up_parent and the likes is good for us. I believe that if this is only for an internal use, than it should be an internal event.
That was the moto (for having the args, send the values only when needed, and remove the args before submitting to end user). Yes, we can create another event, but it would be the 3rd sched_process_fork event.
However, the question here is what do we do with the analyze mode?
The analyze mode will need this arguments, no?
Analyze mode nowadays don't do any kind of "process event" approach, so it wouldn't be ready even if we had something different. I consider this as "preparing the terrain" but changes will be needed in any case.
There was a problem hiding this comment.
It was agreed that the analyze mode will be dealt in v0.20 most likely (and an issue will be opened for that).
There was a problem hiding this comment.
I'm keeping the OPT_FORK_PROCTREE because there is extra processing in getting leader and up_parent information that isn't really needed if process tree is not using events source.
I'm keeping the argument removal not to create a 3rd sched_process_fork event (besides the regular and the signal one). With that, the argument removal logic will be kept so we don't expose a big amount of arguments for SchedProcessFork event to the user (and up_parent wouldn't make much sense in that regard).
With that, I'm either solving, mitigating or workarounding all the concerns brought and yet being functional in time for the release. We can always change things later.
| save_to_submit_buf(&p.event->args_buf, (void *) &child_start_time, sizeof(u64), 9); | ||
|
|
||
| // Process tree information (if needed). | ||
| if (p.config->options & OPT_FORK_PROCTREE) { |
There was a problem hiding this comment.
We still need it.
My thought here is the following - if we want to have different arguments than the normal event, we should create a new event and submit it with the same first arguments and add on top of it the additional arguments (we do the same with magic_write I think).
We already have the concept of internal events, so I think it would be cleaner.
It is not impossible, although it is unlikely, that a fork/exec/exit event arrives first in the regular events pipeline. There is also a possibility that the signal event is lost. This change allows tracee to choose which source of events the process tree should be fed with. Using the control plane (and the fork, exec and exit signal events) is preferrable, but user can also opt to use regular sched events OR even both. There is also another need for this: the analyze mode. If the signatures rely in data source entries to work, when running tracee analyze mode there will be a need to "process events" from the regular pipeline in a way that those data sources exist in memory for the signature processing as well (TBD later). There is also the case where the pipeline is almost empty, and the userland (and go runtime) context switching may cause one event processor to need proc tree data that hasn't yet been saved. Having "both" as the source for proc tree is needed in this case. This commit also: - creates a generic way to normalize timing args to relative time (or not)
commit 0ac5861 (HEAD -> proctreestuff, rafaeldtinoco/proctreestuff)
Author: Rafael David Tinoco [email protected]
Date: Thu Sep 21 23:37:10 2023
commit 05bedbc
Author: Rafael David Tinoco [email protected]
Date: Tue Sep 19 08:38:11 2023