Re: [PATCH] eliminte NMI entry/ exit code

[George Anzinger]

Zachary Amsden wrote:
> George Anzinger wrote:
>
> > Nick Piggin wrote:
> >
> > > George Anzinger wrote:
> > >
> > > > The NMI entry and exit code fiddles with bits in the preempt count.  
> > > > If an NMI happens while some other code is doing the same, bits will 
> > > > be lost.  This patch removes this modify code from the NMI path till 
> > > > we can come up with something better.
> > >
> > > Humour me for a minute here...
> > > NMI restores preempt_count back to its old value upon exit, right?
> > > So what does a race case look like?
> >
> >
> >
> > Normal code                   NMI
> > fetch preempt_count
> > add                   <-----  interrupt here add and store then 
> > subtract and store, darn!
> > store preempt_count
> >
> > Ok, no problem.
> >
> > The problem is in the RT code when PREEMPT_DEBUG is on.  The tests for 
> > reasonable counts fail because of the rather undefined state when NMI 
> > picks up the word.  The failure is on the NMI side... 
>
>
>
> So NMI changing the preempt count and restoring in the middle of a RWM 
> is not the problem.  Thus I don't understand what the issue is.  NMI 
> must undo all side effects.  Does the PREEMPT_DEBUG code check the count 
> somewhere within the NMI handler?  If so, shouldn't the proper fix be to 
> make that code aware that it could be running inside of an NMI and/or 
> ensure that code is not called from within the NMI handler?

Yes that is the problem.  The sanity check in PREEMPT_DEBUG fails when 
called from the NMI handler.
>


--
George Anzinger   george@xxxxxxxxxx
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/