[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170406195748.68f1d0fb@grimm.local.home>
Date: Thu, 6 Apr 2017 19:57:48 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 3/4] tracing: Add stack_tracer_disable/enable()
functions
On Thu, 6 Apr 2017 15:08:21 -0700
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> On Thu, Apr 06, 2017 at 05:23:48PM -0400, Steven Rostedt wrote:
> > On Thu, 6 Apr 2017 13:21:17 -0700
> > "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> >
> > > > My worry is that we add another caller that doesn't disable interrupts
> > > > or preemption.
> > > >
> > > > I could add a __stack_trace_disable() that skips the disabling of
> > > > preemption, as the "__" usually denotes the call is "special".
> > >
> > > Given that interrupts are disabled at that point, and given also that
> > > NMI skips stack tracing if growth is required, could we just leave
> > > out the stack_tracer_disable() and stack_tracer_enable()?
> >
> > There may be other use cases. Hmm, maybe I'll just have it do a check
> > to make sure preemption is disabled. Something like:
> >
> > if (IS_ENABLED(CONFIG_DEBUG_PREEMPT))
> > WARN_ON_ONCE(!preempt_count());
>
> This in the include/linux/ftrace.h file so that it can be inlined?
> That makes sense to me.
>
Hah, I already had that part (inlining) written. It's a separate patch
though. I'll post another series tomorrow.
-- Steve
Powered by blists - more mailing lists