[lkml]   [2008]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RT 2/2] ftrace: fix elevated preempt_count in wakeup-tracer

On Tue, 19 Aug 2008, Gregory Haskins wrote:
> >
> > Is preempt_count > 1 at all times here?
> >
> > If not, it might drop to 0 and any interrupt might cause preemption -
> > and its not obvious to me that that is actually correct.
> >
> According to Steve, we are already in an interrupt-disabled section here, but
> I will defer to him. He suggested I try this over an IRC conversation when I
> noticed a strange wakeup trace, and it seems to have solved the problem.



We disable preemption, do a per_cpu check, if we are not nested we grab
disable interrupts and grab the spin lock.

The issue that Gregory brought up, was that the tracer would always show
that preemption was disabled, when it really wasn't. It was recording the
preempt disabled that the trace function itself made. The answer was
simply to do as Greg did, and enable preemption (but interrupts are
still disabled), call the function tracer, then disable preemption again
(to match the outside preemption enabling.

> Im really sending this patch more of a reminder to Steve that he was going to
> fix this, rather than to accept my patch as is. Of course I don't mind if it
> is accepted as is, and I can make the prologue/comments more descriptive if
> necessary. But if Steve wants to do something like fold this into his ftrace
> series, that is fine too. I just didn't want it to be forgotten ;)

Greg thanks, otherwise I would have probably forgotten it ;-)

-- Steve

 \ /
  Last update: 2008-08-19 15:47    [W:0.050 / U:95.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site