linux-kernel - Re: [RFC 1/2] rcu: Do prepare and cleanup idle depending on in

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180620114335.7a314642@gandalf.local.home>
Date:   Wed, 20 Jun 2018 11:43:35 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     Byungchul Park <byungchul.park@....com>, jiangshanlai@...il.com,
        josh@...htriplett.org, mathieu.desnoyers@...icios.com,
        linux-kernel@...r.kernel.org, kernel-team@....com,
        joel@...lfernandes.org
Subject: Re: [RFC 1/2] rcu: Do prepare and cleanup idle depending on
 in_nmi()

On Wed, 20 Jun 2018 07:50:58 -0700
"Paul E. McKenney" <paulmck@...ux.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.park@....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