On Mon, May 08, 2017 at 02:47:29PM -0500, Josh Poimboeuf wrote:
> On Mon, May 08, 2017 at 03:13:22PM -0400, Steven Rostedt wrote:
[ . . . ]
> > If rcu is not watching, calling rcu_enter_irq() will have it watch
> > again. Even in NMI context I believe.
>
> What if you get an NMI while running in rcu_dynticks_eqs_enter() before
> it increments rdtp->dynticks? Will rcu_enter_irq() still work from the
rcu_irq_enter()
> NMI?
The rcu_nmi_enter() function willl notice that RCU is not watching, and
will therefore atomically increment RCU's dynticks-idle counter, which
will be atomically incremented again upon return. Since the bottom bit
of this counter controls whether or not RCU is watching, RCU will be
watching during the NMI, will stop watching upon return from the NMI,
which restores state so as to allow rcu_irq_enter() to cause RCU to once
again watch. (NMI algorithm due to Andy Lutomirski.)
> I'm just trying to understand what are the cases where rcu_enter_irq()
> *doesn't* work from an ftrace handler.
It doesn't work from an NMI handler. Aside from possible architecture
specific special cases, it should work everywhere else.
> > > I wonder if there's some way to solve this by changing RCU code, but I'm
> > > not familiar enough with RCU to have any ideas there.
> >
> > You don't want to go there.
>
> I believe you :-)
Adding a notrace seems simple enough, but some care is indeed required
for more pervasive changes to RCU. ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
