linux-kernel - Re: [PATCH 2/2] perf hist: Fix bogus profiles when filters are enabled

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: <Z4BGuYG-V9H4wk9i@google.com>
Date: Thu, 9 Jan 2025 13:59:21 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: irogers@...gle.com, linux-perf-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] perf hist: Fix bogus profiles when filters are
 enabled

On Wed, Jan 08, 2025 at 08:36:54AM +0100, Dmitry Vyukov wrote:
> When a filtered column is not present in the sort order, profiles become
> arbitrary broken. Filtered and non-filtered entries are collapsed
> together, and the filtered-by field ends up with a random value (either
> from a filtered or non-filtered entry). If we end up with filtered
> entry/value, then the whole collapsed entry will be filtered out and will
> be missing in the profile. If we end up with non-filtered entry/value,
> then the overhead value will be wrongly larger (include some subset
> of filtered out samples).
> 
> This leads to very confusing profiles. The problem is hard to notice,
> and if noticed hard to understand. If the filter is for a single value,
> then it can be fixed by adding the corresponding field to the sort order
> (provided user understood the problem). But if the filter is for multiple
> values, it's impossible to fix b/c there is no concept of binary sorting
> based on filter predicate (we want to group all non-filtered values in
> one bucket, and all filtered values in another).
> 
> Examples of affected commands:
> perf report --tid=123
> perf report --sort overhead,symbol --comm=foo,bar
> 
> Fix this by considering filtered status as the highest priority
> sort/collapse predicate.

Do you mean when you specify filters not in a sort list?

I guess it's an undefined behavior.. probably better to warn users not
to do that and exit.  The hist entries are built using only the fields
in the sort list.  Filtering by unspecified fields would be meaningless
and won't work well IMHO.

> 
> As a side effect this effectively adds a new feature of showing profile
> where several lines are combined based on arbitrary filtering predicate.
> For example, showing symbols from binaries foo and bar combined together,
> but not from other binaries; or showing combined overhead of several
> particular threads.

I'm not sure I'm following.  I'm seeing this even with your change.

Without filters:

  $ ./perf report -s dso --stdio -q
      98.41%  perf                
       1.11%  [kernel.kallsyms]   
       0.41%  ld-linux-x86-64.so.2
       0.05%  libLLVM-16.so.1     
       0.03%  libc.so.6           
  
  
With filter:

  $ ./perf report -s dso -d '[kernel.kallsyms],libc.so.6' --stdio -q
       1.11%  [kernel.kallsyms]
       0.03%  libc.so.6        

You said you want to have them combined together, right?
But I think the current behavior makes more sense.

Thanks,
Namhyung

> 
> Signed-off-by: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: Namhyung Kim <namhyung@...nel.org>
> Cc: Ian Rogers <irogers@...gle.com>
> Cc: linux-perf-users@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> ---
>  tools/perf/util/hist.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index 8e4e844425370..b70170d854a0c 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -1303,9 +1303,18 @@ hist_entry__cmp_impl(struct perf_hpp_list *hpp_list, struct hist_entry *left,
>  	typedef int64_t (*fn_t)(struct perf_hpp_fmt *, struct hist_entry *, struct hist_entry *);
>  	struct hists *hists = left->hists;
>  	struct perf_hpp_fmt *fmt;
> -	int64_t cmp = 0;
> +	int64_t cmp;
>  	fn_t fn;
>  
> +	/*
> +	 * Never collapse filtered and non-filtered entries.
> +	 * Note this is not the same as having an extra (invisible) fmt
> +	 * that corresponds to the filtered status.
> +	 */
> +	cmp = (int64_t)!!left->filtered - (int64_t)!!right->filtered;
> +	if (cmp)
> +		return cmp;
> +
>  	perf_hpp_list__for_each_sort_list(hpp_list, fmt) {
>  		if (ignore_dynamic && perf_hpp__is_dynamic_entry(fmt) &&
>  		    !perf_hpp__defined_dynamic_entry(fmt, hists))
> -- 
> 2.47.1.613.gc27f4b7a9f-goog
>