Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp791375ybv; Wed, 19 Feb 2020 09:16:46 -0800 (PST) X-Google-Smtp-Source: APXvYqwOJgDJYbWkzCt6mUJC8/HrfLEVozfzAx1iPUvz1zV/tXBAbul62V5px8W4YfQfg6eG3o0f X-Received: by 2002:a05:6830:1d8b:: with SMTP id y11mr21238751oti.4.1582132606232; Wed, 19 Feb 2020 09:16:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582132606; cv=none; d=google.com; s=arc-20160816; b=bNqYnSR7GpQqyb3aD8eVkkn/3Pnc5a41QUi5CffkhOuh+PN7eIVHEvuPd7UNl583Y3 PsfUDm8yNJ+wMW3sroswDWcsvCcDTtbgV3zTqpkRKwUqVMPJxx+p/cA22sJ0CKzukrvD Rb3CwXuHnVoLP2pH7XWeMeP/HPvnpJY8zhF2rB1QTXcNAOg4EWALnjU/UN5KDc0M4k04 3IXuuEVYescSjCiNQEoNLiF1/5+kibwQ931fqQlkZhwbPt5J0cFv6bJnCkpCbTgSMsrx ksstiMUwXX0eN31b8nIyKZ4roRnOyRRjIPkHITEJK3bNIMFykMXLj3fRWZqHunSXNaVQ rq+w== 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; bh=gTI/eERNTAdf8R4a+yxmfBoOhcotdWMTa9+zoR1bPnk=; b=vmjR4+1DAESNuZMnZvd5eph2MHZEaWQjbUDEE3K0mbHH9HXlJTmqbaHhV0MphHCf9u 9au0mwVYUIzqKKPk1kOiFHdXPz4JD3NIju54R8cwpJ8ytB306BJ0I1wXxR+wi4uhY1ne MHsqAuVV1H31+DYRK7ZcaJsJ9sSMh8sXBr82x0t7jdgLJmrGt7ajq2GxkZ4Q3UZmttWy WPfU/QoeicvF/vRa4G2Eoza3K8gX4LAeZKanEoQeK9NLWjm5qWcZVQc1yAfje44p0XJF sFpJn3vbECszDqEvJTkWUsc+FkHVemrE/GgtYE8mBE8UqvwDfB2h3C+AYGqwfO+j8KlN aq7g== 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 t1si198518otp.25.2020.02.19.09.16.33; Wed, 19 Feb 2020 09:16:46 -0800 (PST) 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 S1726667AbgBSRQN (ORCPT + 99 others); Wed, 19 Feb 2020 12:16:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:41658 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726539AbgBSRQN (ORCPT ); Wed, 19 Feb 2020 12:16:13 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 E448724672; Wed, 19 Feb 2020 17:16:10 +0000 (UTC) Date: Wed, 19 Feb 2020 12:16:09 -0500 From: Steven Rostedt To: "Paul E. McKenney" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, joel@joelfernandes.org, gregkh@linuxfoundation.org, gustavo@embeddedor.com, tglx@linutronix.de, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, luto@kernel.org, tony.luck@intel.com, frederic@kernel.org, dan.carpenter@oracle.com, mhiramat@kernel.org Subject: [PATCH] rcu/kprobes: Comment why rcu_nmi_enter() is marked NOKPROBE Message-ID: <20200219121609.45548925@gandalf.local.home> In-Reply-To: <20200219163156.GY2935@paulmck-ThinkPad-P72> References: <20200219144724.800607165@infradead.org> <20200219150744.661923520@infradead.org> <20200219163156.GY2935@paulmck-ThinkPad-P72> X-Mailer: Claws Mail 3.17.3 (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 From: Steven Rostedt (VMware) It's confusing that rcu_nmi_enter() is marked NOKPROBE and rcu_nmi_exit() is not. One may think that the exit needs to be marked for the same reason the enter is, as rcu_nmi_exit() reverts the RCU state back to what it was before rcu_nmi_enter(). But the reason has nothing to do with the state of RCU. The breakpoint handler (int3 on x86) must not have any kprobe on it until the kprobe handler is called. Otherwise, it can cause an infinite recursion and crash the machine. It just so happens that rcu_nmi_enter() is called by the int3 handler before the kprobe handler can run, and therefore needs to be marked as NOKPROBE. Comment this to remove the confusion to why rcu_nmi_enter() is marked NOKPROBE but rcu_nmi_exit() is not. Link: https://lore.kernel.org/r/20200213163800.5c51a5f1@gandalf.local.home Signed-off-by: Steven Rostedt (VMware) --- diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 1694a6b57ad8..ada7b2b638fb 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -846,6 +846,14 @@ void rcu_nmi_enter(void) { rcu_nmi_enter_common(false); } +/* + * All functions called in the breakpoint trap handler (e.g. do_int3() + * on x86), must not allow kprobes until the kprobe breakpoint handler + * is called, otherwise it can cause an infinite recursion. + * On some archs, rcu_nmi_enter() is called in the breakpoint handler + * before the kprobe breakpoint handler is called, thus it must be + * marked as NOKPROBE. + */ NOKPROBE_SYMBOL(rcu_nmi_enter); /**