Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp925124imm; Wed, 20 Jun 2018 08:45:30 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIDEwVbo3qpBk4tah7yoP0dYfOG25HlcgGjdY84SOYKZKaXiAapV7ebDQaim4qZmwlZCgcP X-Received: by 2002:a62:904c:: with SMTP id a73-v6mr23432144pfe.145.1529509530331; Wed, 20 Jun 2018 08:45:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529509530; cv=none; d=google.com; s=arc-20160816; b=a95KIwLEIIBAGmOunbqXfi5M0o6YgvxxEiv+tR7bJ5qX7F3Me2hBFHG5637+JusdmB 39Nu7GcMlWu7E3zBYtErTwxDvu2A1vCf2RUzAWAddSaktkZCmCvu7aE9I3mOguaik98f nwsmhEYC8D8fZPrrtxkMIAF1OoxJphOHHfocwrm76rO+KerQ7KQZzOCxZ96p4Ylo6kk8 +ZhjQpqecXIKeaUhayZowtFvnEGPgKm52zah4rsLFTpaaelPlwZ6tRds7QMhnutSq3aR Z10JEtN1UYTDeXHwYKLIeXo9CijZRU+AezBwUBlGLnVzPKM0INsm2su8qjbP3LaqJs9G R5Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=glqYbUalo7cooMJXE2d+asrW0nvib4GTt0iP6oiB9vo=; b=tYTe574za+4f+z9zqPrNgVm+sooR04Txt8FEc4LB2r2sLSfGy6ABJACJVV3K8t0EMH 2AC9mwAkO4qsBxPaHvLxYG0MJj8UB8vslvHocDWJnnWBdKBMab8iyyM4G/29iziOpXpz 0Ml4FDJxDsEaBRC+op5AV79HQHK/yvRKNQ5UlROA7b2zu+7vpl1CaBcFCcPeVRIkWw29 REYjM70xAPruvDroZZTRAaZVSnyX7MF0iwNtf7A1R+qUWnUb/0Mqb56iLMAF5jAHIdt9 j+1v96QjN3Of8boTgPRQ9UQV/BqY0xMzQ9yoa1UsFPnByTWMIa2HHr53rFZ/GUKE6h0u rdGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e5-v6si2153947pgs.449.2018.06.20.08.45.15; Wed, 20 Jun 2018 08:45:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754157AbeFTPni (ORCPT + 99 others); Wed, 20 Jun 2018 11:43:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:58690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752827AbeFTPnh (ORCPT ); Wed, 20 Jun 2018 11:43:37 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9BC6A2083A; Wed, 20 Jun 2018 15:43:36 +0000 (UTC) Date: Wed, 20 Jun 2018 11:43:35 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Byungchul Park , jiangshanlai@gmail.com, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org, kernel-team@lge.com, joel@joelfernandes.org Subject: Re: [RFC 1/2] rcu: Do prepare and cleanup idle depending on in_nmi() Message-ID: <20180620114335.7a314642@gandalf.local.home> In-Reply-To: <20180620145058.GP3593@linux.vnet.ibm.com> References: <1529484440-20634-1-git-send-email-byungchul.park@lge.com> <20180620145058.GP3593@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Jun 2018 07:50:58 -0700 "Paul E. McKenney" 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 > > --- > > 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