On Wed, 20 Jun 2018 07:50:58 -0700
"Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> On Wed, Jun 20, 2018 at 05:47:19PM +0900, Byungchul Park wrote:
> > Get rid of dependency on ->dynticks_nmi_nesting.
> >
> > Signed-off-by: Byungchul Park <byungchul.p...@lge.com>
> > ---
> > kernel/rcu/tree.c | 22 ++++++++++------------
> > 1 file changed, 10 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index deb2508..59ae94e 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -797,6 +797,11 @@ void rcu_nmi_exit(void)
> > return;
> > }
> >
> > + if (!in_nmi()) {
>
> Is in_nmi() sufficiently reliable for use here? In the past, there have
> been tracepoints that invoked these functions between the time that the
> handlers were entered and the time that software updated the state so that
> the various handler-check functions (such as in_nmi()) would return true.
>
> Steve, has there been any change in this situation?
>
There shouldn't be any "trace events", but what we had to deal with was
function tracing. And in the near future, we will be getting "function
based events" that will allow you to create an event in any function.
That said, even the function tracer shouldn't be called from the time
the NMI triggers to "in_nmi()" is set. Because there's some function
tracer callbacks that should not be executed from an NMI, and I use
in_nmi() to determine if they get called or not.
-- Steve
