From patchwork Tue Sep 6 18:00:04 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Paul E. McKenney" X-Patchwork-Id: 3925 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id E221123FCB for ; Wed, 7 Sep 2011 06:20:58 +0000 (UTC) Received: from mail-fx0-f52.google.com (mail-fx0-f52.google.com [209.85.161.52]) by fiordland.canonical.com (Postfix) with ESMTP id D6D89A186A3 for ; Wed, 7 Sep 2011 06:20:58 +0000 (UTC) Received: by mail-fx0-f52.google.com with SMTP id 18so398985fxd.11 for ; Tue, 06 Sep 2011 23:20:58 -0700 (PDT) Received: by 10.223.4.133 with SMTP id 5mr3104417far.81.1315376458550; Tue, 06 Sep 2011 23:20:58 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.152.11.8 with SMTP id m8cs127789lab; Tue, 6 Sep 2011 23:20:58 -0700 (PDT) Received: by 10.151.143.13 with SMTP id v13mr3426048ybn.78.1315376456265; Tue, 06 Sep 2011 23:20:56 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by mx.google.com with ESMTPS id d39si2518110ybl.23.2011.09.06.23.20.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 23:20:55 -0700 (PDT) Received-SPF: pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.182.141 as permitted sender) client-ip=32.97.182.141; Authentication-Results: mx.google.com; spf=pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.182.141 as permitted sender) smtp.mail=paulmck@linux.vnet.ibm.com Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Wed, 7 Sep 2011 02:20:54 -0400 Received: from d01relay05.pok.ibm.com ([9.56.227.237]) by us.ibm.com ([192.168.1.101]) with XMail ESMTP; Wed, 7 Sep 2011 02:20:52 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p876KqWO138134 for ; Wed, 7 Sep 2011 02:20:52 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p876KjqR005993 for ; Wed, 7 Sep 2011 02:20:51 -0400 Received: from paulmck-ThinkPad-W500 (dyn9050016039.mts.ibm.com [9.50.16.39] (may be forged)) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p876KYCh004549; Wed, 7 Sep 2011 02:20:43 -0400 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id A1B5113F872; Tue, 6 Sep 2011 11:00:51 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org Cc: mingo@elte.hu, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca, josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, Valdis.Kletnieks@vt.edu, dhowells@redhat.com, eric.dumazet@gmail.com, darren@dvhart.com, patches@linaro.org, "Paul E. McKenney" Subject: [PATCH tip/core/rcu 10/55] rcu: Fix RCU's NMI documentation Date: Tue, 6 Sep 2011 11:00:04 -0700 Message-Id: <1315332049-2604-10-git-send-email-paulmck@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.3.2 In-Reply-To: <20110906180015.GA2560@linux.vnet.ibm.com> References: <20110906180015.GA2560@linux.vnet.ibm.com> x-cbid: 11090706-6078-0000-0000-000000711800 It has long been the case that the architecture must call nmi_enter() and nmi_exit() rather than irq_enter() and irq_exit() in order to permit RCU read-side critical sections in NMIs. Catch the documentation up with reality. Signed-off-by: Paul E. McKenney Acked-by: Mathieu Desnoyers --- Documentation/RCU/NMI-RCU.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt index a8536cb..84e4f9c 100644 --- a/Documentation/RCU/NMI-RCU.txt +++ b/Documentation/RCU/NMI-RCU.txt @@ -95,7 +95,7 @@ not to return until all ongoing NMI handlers exit. It is therefore safe to free up the handler's data as soon as synchronize_sched() returns. Important note: for this to work, the architecture in question must -invoke irq_enter() and irq_exit() on NMI entry and exit, respectively. +invoke nmi_enter() and nmi_exit() on NMI entry and exit, respectively. Answer to Quick Quiz