mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: [PATCH RFC] trace: correct off by one preempt counter while recording the trace-event
Date: Fri, 17 Jun 2016 17:47:48 -0400	[thread overview]
Message-ID: <20160617174748.2ed5537e@gandalf.local.home> (raw)
In-Reply-To: <20160525132537.GA10808@linutronix.de>

On Wed, 25 May 2016 15:25:37 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> ---
> I am not sure if this is the only spot that needs correction of the
> preemption counter. If it is it could be corrected directly in
> trace_event_buffer_reserve().
> 
>  include/linux/tracepoint.h  | 13 +++++++++++++
>  kernel/trace/trace_events.c |  2 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index be586c632a0c..12cb3bb40c1c 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -33,6 +33,19 @@ struct trace_enum_map {
>  
>  #define TRACEPOINT_DEFAULT_PRIO	10
>  
> +/*
> + * The preempt count recorded in trace_event_raw_event_# are off by one due to
> + * rcu_read_lock_sched_notrace() in __DO_TRACE. This is corrected here.
> + */
> +static inline int event_preempt_count(void)
> +{
> +#ifdef CONFIG_PREEMPT
> +	return preempt_count() - 1;
> +#else
> +	return 0;
> +#endif
> +}
> +
>  extern int
>  tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
>  extern int
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 52c4fffaddcd..90b40cf6ec98 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -245,7 +245,7 @@ void *trace_event_buffer_reserve(struct trace_event_buffer *fbuffer,
>  		return NULL;
>  
>  	local_save_flags(fbuffer->flags);
> -	fbuffer->pc = preempt_count();
> +	fbuffer->pc = event_preempt_count();
>  	fbuffer->trace_file = trace_file;
>  
>  	fbuffer->event =

Hmm, what about this? This is a bit cleaner IMO.

-- Steve

>From c95e5401296b643d3ad8a331b23e2976459cdf11 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
Date: Fri, 17 Jun 2016 17:40:58 -0400
Subject: [PATCH] tracing: Show the preempt count of when the event was called

Because tracepoint callbacks are done with preemption enabled, the trace
events are always called with preempt disable due to the
rcu_read_lock_sched_notrace() in __DO_TRACE(). This causes the preempt count
shown in the recorded trace event to be inaccurate. It is always one more
that what the preempt_count was when the tracepoint was called.

If CONFIG_PREEMPT is enabled, subtract 1 from the preempt_count before
recording it in the trace buffer.

Link: http://lkml.kernel.org/r/20160525132537.GA10808@linutronix.de

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace_events.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index fd449eb138cf..03c0a48c3ac4 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -261,6 +261,14 @@ void *trace_event_buffer_reserve(struct trace_event_buffer *fbuffer,
 
 	local_save_flags(fbuffer->flags);
 	fbuffer->pc = preempt_count();
+	/*
+	 * If CONFIG_PREEMPT is enabled, then the tracepoint itself disables
+	 * preemption (adding one to the preempt_count). Since we are
+	 * interested in the preempt_count at the time the tracepoint was
+	 * hit, we need to subtract one to offset the increment.
+	 */
+	if (IS_ENABLED(CONFIG_PREEMPT))
+		fbuffer->pc--;
 	fbuffer->trace_file = trace_file;
 
 	fbuffer->event =
-- 
1.9.3

      reply	other threads:[~2016-06-17 21:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 13:25 Sebastian Andrzej Siewior
2016-06-17 21:47 ` Steven Rostedt [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=20160617174748.2ed5537e@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®