On Wed, Feb 19, 2020 at 08:31:56AM -0800, Paul E. McKenney wrote: > On Wed, Feb 19, 2020 at 03:47:29PM +0100, Peter Zijlstra wrote: > > From: Paul E. McKenney <paulmck@xxxxxxxxxx> > > > > The rcu_nmi_enter_common() and rcu_nmi_exit_common() functions take an > > "irq" parameter that indicates whether these functions are invoked from > > an irq handler (irq==true) or an NMI handler (irq==false). However, > > recent changes have applied notrace to a few critical functions such > > that rcu_nmi_enter_common() and rcu_nmi_exit_common() many now rely > > on in_nmi(). Note that in_nmi() works no differently than before, > > but rather that tracing is now prohibited in code regions where in_nmi() > > would incorrectly report NMI state. > > > > This commit therefore removes the "irq" parameter and inlines > > rcu_nmi_enter_common() and rcu_nmi_exit_common() into rcu_nmi_enter() > > and rcu_nmi_exit(), respectively. > > > > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> > > Again, thank you. > > Would you like to also take the added comment for NOKPROBE_SYMBOL(), > or would you prefer that I carry that separately? (I dropped it for > now to avoid the conflict with the patch below.) > > Here is the latest version of that comment, posted by Steve Rostedt. > > Thanx, Paul > > /* > * All functions called in the breakpoint trap handler (e.g. do_int3() > * on x86), must not allow kprobes until the kprobe breakpoint handler > * is called, otherwise it can cause an infinite recursion. > * On some archs, rcu_nmi_enter() is called in the breakpoint handler > * before the kprobe breakpoint handler is called, thus it must be > * marked as NOKPROBE. > */ Oh right, let me stick that in a separate patch. Best we not loose that I suppose ;-)
