All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Bristot de Oliveira <bristot@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Tom Zanussi <zanussi@kernel.org>
Subject: Re: [PATCH] tracing/histogram: Fix sorting on old "cpu" value
Date: Wed, 2 Mar 2022 09:00:27 +0100	[thread overview]
Message-ID: <fc5793b2-e4f7-8639-3bbb-c934cd909c5c@kernel.org> (raw)
In-Reply-To: <20220301225728.100f17af@gandalf.local.home>

On 3/2/22 04:57, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
> 
> When trying to add a histogram against an event with the "cpu" field, it
> was impossible due to "cpu" being a keyword to key off of the running CPU.
> So to fix this, it was changed to "common_cpu" to match the other generic
> fields (like "common_pid"). But since some scripts used "cpu" for keying
> off of the CPU (for events that did not have "cpu" as a field, which is
> most of them), a backward compatibility trick was added such that if "cpu"
> was used as a key, and the event did not have "cpu" as a field name, then
> it would fallback and switch over to "common_cpu".
> 
> This fix has a couple of subtle bugs. One was that when switching over to
> "common_cpu", it did not change the field name, it just set a flag. But
> the code still found a "cpu" field. The "cpu" field is used for filtering
> and is returned when the event does not have a "cpu" field.
> 
> This was found by:
> 
>   # cd /sys/kernel/tracing
>   # echo hist:key=cpu,pid:sort=cpu > events/sched/sched_wakeup/trigger
>   # cat events/sched/sched_wakeup/hist
> 
> Which showed the histogram unsorted:
> 
> { cpu:         19, pid:       1175 } hitcount:          1
> { cpu:          6, pid:        239 } hitcount:          2
> { cpu:         23, pid:       1186 } hitcount:         14
> { cpu:         12, pid:        249 } hitcount:          2
> { cpu:          3, pid:        994 } hitcount:          5
> 
> Instead of hard coding the "cpu" checks, take advantage of the fact that
> trace_event_field_field() returns a special field for "cpu" and "CPU" if
> the event does not have "cpu" as a field. This special field has the
> "filter_type" of "FILTER_CPU". Check that to test if the returned field is
> of the CPU type instead of doing the string compare.
> 
> Also, fix the sorting bug by testing for the hist_field flag of
> HIST_FIELD_FL_CPU when setting up the sort routine. Otherwise it will use
> the special CPU field to know what compare routine to use, and since that
> special field does not have a size, it returns tracing_map_cmp_none.
> 
> Cc: stable@vger.kernel.org
> Fixes: 1e3bac71c505 ("tracing/histogram: Rename "cpu" to "common_cpu"")
> Reported-by: Daniel Bristot de Oliveira <bristot@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

It works!

Tested-by: Daniel Bristot de Oliveira <bristot@kernel.org>

-- Daniel

      reply	other threads:[~2022-03-02  8:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  3:57 [PATCH] tracing/histogram: Fix sorting on old "cpu" value Steven Rostedt
2022-03-02  8:00 ` Daniel Bristot de Oliveira [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc5793b2-e4f7-8639-3bbb-c934cd909c5c@kernel.org \
    --to=bristot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=zanussi@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.