Currently, the userspace RV tool skips trace events triggered by the RV
tool itself, this can be changed by passing the parameter -s, which sets
the variable config_my_pid to 0 (instead of the tool's PID).
The current condition for per-task monitors (config_has_id) does not
check that config_my_pid isn't 0 to skip. In case we pass -s, we show
events triggered by RV but don't show those triggered by idle (PID 0).

Fix the condition to account this scenario.

Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface")
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
 tools/verification/rv/src/in_kernel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/verification/rv/src/in_kernel.c b/tools/verification/rv/src/in_kernel.c
index c0dcee795c0de..72b03bae021cd 100644
--- a/tools/verification/rv/src/in_kernel.c
+++ b/tools/verification/rv/src/in_kernel.c
@@ -429,7 +429,7 @@ ikm_event_handler(struct trace_seq *s, struct tep_record *record,
 
 	tep_get_common_field_val(s, trace_event, "common_pid", record, &pid, 1);
 
-	if (config_has_id && (config_my_pid == id))
+	if (config_my_pid && config_has_id && (config_my_pid == id))
 		return 0;
 	else if (config_my_pid && (config_my_pid == pid))
 		return 0;
-- 
2.50.1

On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote:
> Currently, the userspace RV tool skips trace events triggered by the RV
> tool itself, this can be changed by passing the parameter -s, which sets
> the variable config_my_pid to 0 (instead of the tool's PID).
> The current condition for per-task monitors (config_has_id) does not
> check that config_my_pid isn't 0 to skip. In case we pass -s, we show
> events triggered by RV but don't show those triggered by idle (PID 0).
> 
> Fix the condition to account this scenario.

The distinction between !my_pid and has_id is that you can in fact trace
pid-0 if you want?

> Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface")
> Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> ---
>  tools/verification/rv/src/in_kernel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/verification/rv/src/in_kernel.c b/tools/verification/rv/src/in_kernel.c
> index c0dcee795c0de..72b03bae021cd 100644
> --- a/tools/verification/rv/src/in_kernel.c
> +++ b/tools/verification/rv/src/in_kernel.c
> @@ -429,7 +429,7 @@ ikm_event_handler(struct trace_seq *s, struct tep_record *record,
>  
>  	tep_get_common_field_val(s, trace_event, "common_pid", record, &pid, 1);
>  
> -	if (config_has_id && (config_my_pid == id))
> +	if (config_my_pid && config_has_id && (config_my_pid == id))
>  		return 0;
>  	else if (config_my_pid && (config_my_pid == pid))
>  		return 0;
> -- 
> 2.50.1
>

On Wed, 2025-07-16 at 13:50 +0200, Peter Zijlstra wrote:
> On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote:
> > Currently, the userspace RV tool skips trace events triggered by
> > the RV
> > tool itself, this can be changed by passing the parameter -s, which
> > sets
> > the variable config_my_pid to 0 (instead of the tool's PID).
> > The current condition for per-task monitors (config_has_id) does
> > not
> > check that config_my_pid isn't 0 to skip. In case we pass -s, we
> > show
> > events triggered by RV but don't show those triggered by idle (PID
> > 0).
> > 
> > Fix the condition to account this scenario.
> 
> The distinction between !my_pid and has_id is that you can in fact
> trace
> pid-0 if you want?
> 

Yes pretty much, no flag is meant to skip events from pid-0.


has_id is used to distinguish between per-cpu/global monitors (they
don't have id) and per-task monitors (the id is the pid).

The case with !has_id is correctly checking for both my_pid != 0 while
skipping events associated to my_pid (rv thread's PID).

In the other case we end up with:
* -s skipping events generated by the tool (correct)
* omitting -s skips events generated by pid-0 (undesired)


> > Fixes: 6d60f89691fc ("tools/rv: Add in-kernel monitor interface")
> > Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
> > ---
> >  tools/verification/rv/src/in_kernel.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/verification/rv/src/in_kernel.c
> > b/tools/verification/rv/src/in_kernel.c
> > index c0dcee795c0de..72b03bae021cd 100644
> > --- a/tools/verification/rv/src/in_kernel.c
> > +++ b/tools/verification/rv/src/in_kernel.c
> > @@ -429,7 +429,7 @@ ikm_event_handler(struct trace_seq *s, struct
> > tep_record *record,
> >  
> >  	tep_get_common_field_val(s, trace_event, "common_pid",
> > record, &pid, 1);
> >  
> > -	if (config_has_id && (config_my_pid == id))
> > +	if (config_my_pid && config_has_id && (config_my_pid ==
> > id))
> >  		return 0;
> >  	else if (config_my_pid && (config_my_pid == pid))
> >  		return 0;
> > -- 
> > 2.50.1
> > 

On Wed, Jul 16, 2025 at 02:18:28PM +0200, Gabriele Monaco wrote:
> 
> 
> On Wed, 2025-07-16 at 13:50 +0200, Peter Zijlstra wrote:
> > On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote:
> > > Currently, the userspace RV tool skips trace events triggered by
> > > the RV
> > > tool itself, this can be changed by passing the parameter -s, which
> > > sets
> > > the variable config_my_pid to 0 (instead of the tool's PID).
> > > The current condition for per-task monitors (config_has_id) does
> > > not
> > > check that config_my_pid isn't 0 to skip. In case we pass -s, we
> > > show
> > > events triggered by RV but don't show those triggered by idle (PID
> > > 0).
> > > 
> > > Fix the condition to account this scenario.
> > 
> > The distinction between !my_pid and has_id is that you can in fact
> > trace
> > pid-0 if you want?
> > 
> 
> Yes pretty much, no flag is meant to skip events from pid-0.

> > > -	if (config_has_id && (config_my_pid == id))
> > > +	if (config_my_pid && config_has_id && (config_my_pid == id))

But should we then not write:

	if (config_has_id && (config_my_pid == id))

On Wed, 2025-07-16 at 14:41 +0200, Peter Zijlstra wrote:
> On Wed, Jul 16, 2025 at 02:18:28PM +0200, Gabriele Monaco wrote:
> > On Wed, 2025-07-16 at 13:50 +0200, Peter Zijlstra wrote:
> > > On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote:
> > > > Currently, the userspace RV tool skips trace events triggered by the RV
> > > > tool itself, this can be changed by passing the parameter -s, which
> > > > sets the variable config_my_pid to 0 (instead of the tool's PID). The
> > > > current condition for per-task monitors (config_has_id) does not check
> > > > that config_my_pid isn't 0 to skip. In case we pass -s, we show events
> > > > triggered by RV but don't show those triggered by idle (PID 0).
> > > 
> > > The distinction between !my_pid and has_id is that you can in fact trace
> > > pid-0 if you want?
> > > 
> > Yes pretty much, no flag is meant to skip events from pid-0.
> 
> > > > -	if (config_has_id && (config_my_pid == id))
> > > > +	if (config_my_pid && config_has_id && (config_my_pid == id))
> 
> But should we then not write:
> 
> 	if (config_has_id && (config_my_pid == id))

Sorry, got a bit confused, I flipped the two while describing:
* -s shows traces from RV but skips from pid-0 (unintended)
* omitting -s skips events from RV (correct)

If we are running a per-task monitor config_has_id is always true, we pass -s,
which makes config_my_pid = 0 (intended /not/ to skip RV).
Now when we are about to trace an event from idle (id=0), we skip it, although
we really shouldn't.
That's why we also needs to check for config_my_pid not being 0.

Does it make sense?

Thanks,
Gabriele

On Wed, Jul 16, 2025 at 03:05:50PM +0200, Gabriele Monaco wrote:
> On Wed, 2025-07-16 at 14:41 +0200, Peter Zijlstra wrote:
> > On Wed, Jul 16, 2025 at 02:18:28PM +0200, Gabriele Monaco wrote:
> > > On Wed, 2025-07-16 at 13:50 +0200, Peter Zijlstra wrote:
> > > > On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote:
> > > > > Currently, the userspace RV tool skips trace events triggered by the RV
> > > > > tool itself, this can be changed by passing the parameter -s, which
> > > > > sets the variable config_my_pid to 0 (instead of the tool's PID). The
> > > > > current condition for per-task monitors (config_has_id) does not check
> > > > > that config_my_pid isn't 0 to skip. In case we pass -s, we show events
> > > > > triggered by RV but don't show those triggered by idle (PID 0).
> > > > 
> > > > The distinction between !my_pid and has_id is that you can in fact trace
> > > > pid-0 if you want?
> > > > 
> > > Yes pretty much, no flag is meant to skip events from pid-0.
> > 
> > > > > -	if (config_has_id && (config_my_pid == id))
> > > > > +	if (config_my_pid && config_has_id && (config_my_pid == id))
> > 
> > But should we then not write:
> > 
> > 	if (config_has_id && (config_my_pid == id))
> 
> Sorry, got a bit confused, I flipped the two while describing:
> * -s shows traces from RV but skips from pid-0 (unintended)
> * omitting -s skips events from RV (correct)
> 
> If we are running a per-task monitor config_has_id is always true, we pass -s,
> which makes config_my_pid = 0 (intended /not/ to skip RV).
> Now when we are about to trace an event from idle (id=0), we skip it, although
> we really shouldn't.
> That's why we also needs to check for config_my_pid not being 0.
> 
> Does it make sense?

Sorta, but would it not make sense to use has_pid := -1 for the invalid
case, instead of 0, which is a valid pid?

On Wed, 2025-07-16 at 15:08 +0200, Peter Zijlstra wrote:
> > > > > > -	if (config_has_id && (config_my_pid == id))
> > > > > > +	if (config_my_pid && config_has_id &&
> > > > > > (config_my_pid == id))
> > > 
> > > But should we then not write:
> > > 
> > > 	if (config_has_id && (config_my_pid == id))
> > 
> > Sorry, got a bit confused, I flipped the two while describing:
> > * -s shows traces from RV but skips from pid-0 (unintended)
> > * omitting -s skips events from RV (correct)
> > 
> > If we are running a per-task monitor config_has_id is always true,
> > we pass -s,
> > which makes config_my_pid = 0 (intended /not/ to skip RV).
> > Now when we are about to trace an event from idle (id=0), we skip
> > it, although
> > we really shouldn't.
> > That's why we also needs to check for config_my_pid not being 0.
> > 
> > Does it make sense?
> 
> Sorta, but would it not make sense to use has_pid := -1 for the
> invalid case, instead of 0, which is a valid pid?

Yeah that's another option, I reckon even cleaner since it's currently
misleading..