public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] ftrace / perf 'recursion'
Date: Wed, 17 Aug 2016 16:06:12 +0200	[thread overview]
Message-ID: <20160817140612.GR30192@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160817094932.22a9e768@gandalf.local.home>

On Wed, Aug 17, 2016 at 09:49:32AM -0400, Steven Rostedt wrote:
> On Wed, 17 Aug 2016 12:57:16 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 

> > +static inline notrace void __smp_irq_work_interrupt(void)
> 
> FYI, anything marked "inline" is also marked "notrace", because it only
> gets traced if gcc decides not to inline it, and because that
> "randomness" caused issues in the past, we define all "inline"s to
> include "notrace" so a function marked inline will never be traced
> regardless if gcc decides not to inline it.

Ah, missed that.

> > +static inline notrace void exiting_irq_work(void)
> > +{
> > +#ifdef CONFIG_TRACING
> > +	if (unlikely(1 /* function_tracing_enabled() */)) {
> > +		unsigned long trace_recursion = current->trace_recursion;
> > +
> > +		current->trace_recursion |= 1 << 10; /* TRACE_INTERNAL_IRQ_BIT */
> > +		barrier();
> > +		exiting_irq();
> > +		barrier();
> > +		current->trace_recursion = trace_recursion;
> > +		return;
> > +	}
> > +#endif
> 
> yuck. 

Well, yes ;-)

> This looks very fragile. What happens if perf gets hooked to
> function graph tracing, then this wont help that on function exit.

Not sure what you mean, all callers of this are also notrace. There
should not be any return trampoline pending.

> Also, it will prevent any tracing of NMIs that occur in there.

It should not, see how I only mark the IRQ bit, not the NMI bit.

Could be I misunderstand your recursion bits though....

> I would really like to keep this fix within perf if possible. If
> anything, the flag should just tell the perf function handler not to
> trace, this shouldn't stop all function handlers.

Well, my thinking was that there's a reason most of irq_work is already
notrace. kernel/irq_work.c has CC_FLAGS_FTRACE removed. That seems to
suggest that tracing irq_work is a problem.

tracing also seems to use irq_work..

  reply	other threads:[~2016-08-17 14:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  9:19 [RFC] ftrace / perf 'recursion' Peter Zijlstra
2016-08-17 10:33 ` Peter Zijlstra
2016-08-17 10:57   ` Peter Zijlstra
2016-08-17 13:49     ` Steven Rostedt
2016-08-17 14:06       ` Peter Zijlstra [this message]
2016-08-17 14:25         ` Steven Rostedt
2016-08-17 14:57           ` Peter Zijlstra
2016-08-17 15:04             ` Steven Rostedt

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=20160817140612.GR30192@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --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