On Tue, 2008-08-19 at 09:45 -0400, Steven Rostedt wrote: > 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. Ok good. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
