Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1464596

Re: [RFC] ftrace / perf 'recursion'

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC] ftrace / perf 'recursion'
Date 2016-08-17 16:10 +0200
Message-ID <s79Hz-25o-17@gated-at.bofh.it> (permalink)
References <s75kB-7vR-13@gated-at.bofh.it> <s76qm-8dD-45@gated-at.bofh.it> <s76JH-8kQ-1@gated-at.bofh.it> <s79oe-1IE-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 11:30 +0200
  Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 12:40 +0200
    Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 13:00 +0200
      Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 15:50 +0200
        Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 16:10 +0200
          Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 16:30 +0200
            Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 17:00 +0200
              Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 17:10 +0200

csiph-web