From nobody Wed Dec 17 10:40:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01B4F42070; Tue, 18 Mar 2025 13:56:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306192; cv=none; b=mVdD1CaKeePz5SV5RadFihKYOzPuk+ER57jsGfpJh3w74KPeMS4gbJ21MkojtvZB7sWHCcW3v7IjDpKHldOyQ0RssayXd/WnddZFATQzBqCHymybZ6gs9yT21MEH4vaMDL6Ap8X+tES8htG8k5TPXJpICAqkU0KzKulevRJJB7s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306192; c=relaxed/simple; bh=W3LGO0ftBFKLCw3W6a6ZJzVnMrnFnIssiyirgrpTGtI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gUp7bhFf/yC+gYLEFioZGMDAAmoDZR9xpLhIxbOPpyenMUbIfd0qRGJtR7YhpPn5fy+e6iy/Xae7P+EqjCTpZAnLepWoWScyf9y7en+0Q+LpNH2J0ZjOQtF7bcN9HcUeTbaO0TCiwECEITW/JVaYC1F5J6DNdVMU5cI1430t0bg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r/9jei3W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r/9jei3W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBCEC4CEEA; Tue, 18 Mar 2025 13:56:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742306191; bh=W3LGO0ftBFKLCw3W6a6ZJzVnMrnFnIssiyirgrpTGtI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r/9jei3WezmtaUvY4tb1qTGPPI5jOEYLCvHH3s61FgvO3fzz0kqfWuAV1pp5cXuU0 hvXlgYLLrHeIhO1suLHgZXi4vllKTgz2smJ+glzojzOVyJd/Pb0yr3B84mp+NdnA0N jwi88waI4PVrbvdZOVzj0Ci18QnSQnF3JSQjnnemW12hKbKL1xFhtbS+C1mO38zR9i 5g5PlFZ87VNYkfD9vvYAJDFLvRdcvXfiEHdb1oskHw7P6tbFwcczzZiVNOU1q6j2db qMx/+YYmV8oO1gE5p73Qoy0qBRvcXeu4gfeW0OZYiCcUiN/GEsuJlyq7Aw/tMIHqy+ jvToq4A8cWHfw== From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Boqun Feng , Joel Fernandes , Neeraj Upadhyay , "Paul E . McKenney" , Uladzislau Rezki , Zqiang , rcu Subject: [PATCH 1/2] rcu: Comment on the extraneous delta test on rcu_seq_done_exact() Date: Tue, 18 Mar 2025 14:56:18 +0100 Message-ID: <20250318135619.4300-2-frederic@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250318135619.4300-1-frederic@kernel.org> References: <20250318135619.4300-1-frederic@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The numbers used in rcu_seq_done_exact() lack some explanation behind their magic. Especially after the commit: 85aad7cc4178 ("rcu: Fix get_state_synchronize_rcu_full() GP-start detec= tion") which reported a subtle issue where a new GP sequence snapshot was taken on the root node state while a grace period had already been started and reflected on the global state sequence but not yet on the root node sequence, making a polling user waiting on a wrong already started grace period that would ignore freshly online CPUs. The fix involved taking the snaphot on the global state sequence and waiting on the root node sequence. And since a grace period is first started on the global state and only afterward reflected on the root node, a snapshot taken on the global state sequence might be two full grace periods ahead of the root node as in the following example: rnp->gp_seq =3D rcu_state.gp_seq =3D 0 CPU 0 CPU 1 ----- ----- // rcu_state.gp_seq =3D 1 rcu_seq_start(&rcu_state.gp_seq) // snap =3D 8 snap =3D rcu_seq_snap(&= rcu_state.gp_seq) // Two full GP differen= ces rcu_seq_done_exact(&rnp= ->gp_seq, snap) // rnp->gp_seq =3D 1 WRITE_ONCE(rnp->gp_seq, rcu_state.gp_seq); Add a comment about those expectations and to clarify the magic within the relevant function. Signed-off-by: Frederic Weisbecker Reviewed-by: Paul E. McKenney --- kernel/rcu/rcu.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h index eed2951a4962..7acf1f36dd6c 100644 --- a/kernel/rcu/rcu.h +++ b/kernel/rcu/rcu.h @@ -157,6 +157,13 @@ static inline bool rcu_seq_done(unsigned long *sp, uns= igned long s) * Given a snapshot from rcu_seq_snap(), determine whether or not a * full update-side operation has occurred, but do not allow the * (ULONG_MAX / 2) safety-factor/guard-band. + * + * The token returned by get_state_synchronize_rcu_full() is based on + * rcu_state.gp_seq but it is tested in poll_state_synchronize_rcu_full() + * against the root rnp->gp_seq. Since rcu_seq_start() is first called + * on rcu_state.gp_seq and only later reflected on the root rnp->gp_seq, + * it is possible that rcu_seq_snap(rcu_state.gp_seq) returns 2 full grace + * periods ahead of the root rnp->gp_seq. */ static inline bool rcu_seq_done_exact(unsigned long *sp, unsigned long s) { --=20 2.48.1 From nobody Wed Dec 17 10:40:43 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D8A542070; Tue, 18 Mar 2025 13:56:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306195; cv=none; b=LGw2uqwgGTKOitoqZji611QzpfZuiQeI9kbcs8QR67H+efWa9fPZiyhY4T5WtIA2noD5i27C30NugKgddvrNlkI1hEviukvmEQJwUTNLIj055wD6ekRknZuKnydF9hlSyuVNMSIogCOuQSfkH6IXUe9642gcqAD1QFuzIRmZOwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742306195; c=relaxed/simple; bh=iODjk+JvPaqauEX/2q96+DypdFzdm4oQDx3Dh0AUUnM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qDdjMcFcN416t+AWO/CnniGHoM0kfsdpEdqRvGFQqaea5RAxG5sKHii2cIWHLTBLbKQFRcDDPKK1cMDLYK3FHiAlvCYDED0PXYQe1Hsod5XrA0NcMYnljQbQHJKYrPa27+9Hnrm5Jx0mPcaKX4Si3gg5E5ZH/54u3Um3zj5ucmA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IBZGLSi9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IBZGLSi9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 032F2C4CEE3; Tue, 18 Mar 2025 13:56:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742306194; bh=iODjk+JvPaqauEX/2q96+DypdFzdm4oQDx3Dh0AUUnM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IBZGLSi9eLvvXcHcDdrO8ZxbkAYpOJZfoKuSNaJVIOacScspj7semQyQr5IzUMkyS SX9No4kNGK/RRs+adUhTFcQq6eGsC4Pnuc/0lEp/SzvJUu6FIWKT86SfAjgE7RhySg nfpWJZ6JSkTbguDSTtGYpW1x7SzfGSmgZ+7yhmGbv6ztJlDGLEtdw/Cwg10EdIgwS+ NZZZCOn3zZF2TJdrMVVRRDq1aJyhsUl0Oe9/XyEEYgdwqOUZvHv92M3BoYekxeRw5w Wp0Sh9Lhiqa7NQTcTg/y5UoUAkooUQbivzvmS/wyzHijtGE4QklJu/ryGmvJNoQp+l ETDGUPDHE4dog== From: Frederic Weisbecker To: LKML Cc: Frederic Weisbecker , Boqun Feng , Joel Fernandes , Neeraj Upadhyay , "Paul E . McKenney" , Uladzislau Rezki , Zqiang , rcu Subject: [PATCH 2/2] rcu: Robustify rcu_is_cpu_rrupt_from_idle() Date: Tue, 18 Mar 2025 14:56:19 +0100 Message-ID: <20250318135619.4300-3-frederic@kernel.org> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250318135619.4300-1-frederic@kernel.org> References: <20250318135619.4300-1-frederic@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" RCU relies on the context tracking nesting counter in order to determine if it is running in extended quiescent state. However the context tracking nesting counter is not completely synchronized with the actual context tracking state: * The nesting counter is set to 1 or incremented further _after_ the actual state is set to RCU not watching. (then we know for sure we interrupted RCU not watching) * The nesting counter is set to 0 or decremented further _before_ the actual state is set to RCU watching. Therefore it is safe to assume that if ct_nesting() > 0, RCU is not watching. But if ct_nesting() <=3D 0, RCU is watching except for a tiny window. This hasn't been a problem so far because rcu_is_cpu_rrupt_from_idle() has only been called from interrupts. However the code is confusing and abuses the role of the context tracking nesting counter while there are more accurate indicators available. Clarify and robustify accordingly. Signed-off-by: Frederic Weisbecker --- kernel/rcu/tree.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 79dced5fb72e..90c43061c981 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -367,7 +367,7 @@ EXPORT_SYMBOL_GPL(rcu_momentary_eqs); */ static int rcu_is_cpu_rrupt_from_idle(void) { - long nesting; + long nmi_nesting =3D ct_nmi_nesting(); =20 /* * Usually called from the tick; but also used from smp_function_call() @@ -379,21 +379,28 @@ static int rcu_is_cpu_rrupt_from_idle(void) /* Check for counter underflows */ RCU_LOCKDEP_WARN(ct_nesting() < 0, "RCU nesting counter underflow!"); - RCU_LOCKDEP_WARN(ct_nmi_nesting() <=3D 0, - "RCU nmi_nesting counter underflow/zero!"); =20 - /* Are we at first interrupt nesting level? */ - nesting =3D ct_nmi_nesting(); - if (nesting > 1) + /* Non-idle interrupt or nested idle interrupt */ + if (nmi_nesting > 1) return false; =20 /* - * If we're not in an interrupt, we must be in the idle task! + * Non nested idle interrupt (interrupting section where RCU + * wasn't watching). */ - WARN_ON_ONCE(!nesting && !is_idle_task(current)); + if (nmi_nesting =3D=3D 1) + return true; =20 - /* Does CPU appear to be idle from an RCU standpoint? */ - return ct_nesting() =3D=3D 0; + /* Not in an interrupt */ + if (!nmi_nesting) { + RCU_LOCKDEP_WARN(!in_task() || !is_idle_task(current), + "RCU nmi_nesting counter not in idle task!"); + return !rcu_is_watching_curr_cpu(); + } + + RCU_LOCKDEP_WARN(1, "RCU nmi_nesting counter underflow/zero!"); + + return false; } =20 #define DEFAULT_RCU_BLIMIT (IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD) ? 1= 000 : 10) --=20 2.48.1