linux-kernel - Re: [PATCH v3 01/17] tools/rv: Do not skip idle in trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <77bf0cb4262af4edf78dd0b5233788b358bdc79b.camel@redhat.com>
Date: Wed, 16 Jul 2025 15:13:43 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, 
	linux-trace-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>, Nam Cao
	 <namcao@...utronix.de>, Tomas Glozar <tglozar@...hat.com>, Juri Lelli
	 <jlelli@...hat.com>, Clark Williams <williams@...hat.com>, John Kacur
	 <jkacur@...hat.com>
Subject: Re: [PATCH v3 01/17] tools/rv: Do not skip idle in trace

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..