Re: [PATCH RT 2/2] ftrace: fix elevated preempt_count inwakeup-tracer

[Steven Rostedt]

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.

Exactly.

Peter,

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/