> * Peter Zijlstra (
a.p.zijlstra@chello.nl) wrote:
> > On Sat, 2008-08-30 at 07:10 -0700, Paul E. McKenney wrote:
> > > On Sat, Aug 30, 2008 at 11:33:00AM +0200, Peter Zijlstra wrote:
> > > > On Fri, 2008-08-29 at 17:49 -0700, Paul E. McKenney wrote:
> > > >
> > > > > Some shortcomings:
> > > > >
> > > > > o Entering and leaving dynticks idle mode is a quiescent state,
> > > > > but the current patch doesn't take advantage of this (noted
> > > > > by Manfred). It appears that it should be possible to make
> > > > > nmi_enter() and nmi_exit() provide an in_nmi(), which would make
> > > > > it possible for rcu_irq_enter() and rcu_irq_exit() to figure
> > > > > out whether it is safe to tell RCU about the quiescent state --
> > > > > and also greatly simplify the code.
> > > >
> > > > Already done and available in the -tip tree, curtesy of Mathieu.
> > >
> > > Very cool!!! I see one of his patches at
http://lkml.org/lkml/2008/4/17/342,
> > > but how do I find out which branch of -tip this is on? (I am learning
> > > git, but it is a slow process...)
> > >
> > > This would also simplify preemptable RCU's dyntick interface, removing
> > > the need for proofs.
> >
> > Not sure - my git-foo isn't good enough either :-(
> >
> > All I can offer is that its available in tip/master (the collective
> > merge of all of tip's branches) as commit:
> > 0d84b78a606f1562532cd576ee8733caf5a4aed3, which I found using
> > git-annotate include/linux/hardirq.h
> >
> > How to find from which particular topic branch it came from, I too am
> > clueless.
> >
>
> If you're interested in knowing the topic it came from : it's required
> so a following patch can use a "popf; ret" instead of iret to return
> from trap handlers executed in NMI context. There is an architectural
> problem on x86 causing NMIs to be reactivated after the first iret
> encountered, which leads to NMI handler races if nmi handlers trap. This
> works around the problem by returning from the trap handlers without
> using the iret instruction.
>
> It's useful to Immediate Values which put a temporary breakpoint in the
> instruction stream when proceeding to code modification and also useful
> to LTTng (available in the -lttng tree) which writes tracing data to
> vmap'd memory buffers (which can cause a minor page fault).
>
> I'm glad to see NMI context detection is useful to others too !
