From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 9577AC433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 13:38:04 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S241419AbiCNNjM (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 09:39:12 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33130 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S241536AbiCNNjH (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 09:39:07 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 111B6BC9A
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 06:37:57 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 4CEA161185
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:37:56 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB0E7C340F6;
        Mon, 14 Mar 2022 13:37:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647265075;
        bh=rr6lMXcZFN4o3VbDgDdxjHH2wTI1ygkpoMFDut5z9oY=;
        h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
        b=X3bh7TI4xgrruUgSrEmv/4AuzHcpyQSpJIa0FuZaWaMv4mcshalAfoD36sdz+ns5s
         X3BaROjRbrIlIPwohmsov8p8LfOeXy12c3KnYFe4+8MHwo6XlEY35FttA0T0gi2zRh
         OIDWSmaSnyPEPsecwG/BgcvriCgoHZdQFHKu+EKI0GGrDLgtLYNvZDwvFi0hQmvhbY
         lLtL6tKBTTdgNkbBUx1zqRidLlNJLjGzR9+NAoqlCmsd4JBHxrKpxYhCrLRFGixUNp
         FtMThnu4v3lF1tbd08zq7JvgzlD+8Z5AMpcg+d3t08o8sG+14JeKNm5Zcupk3jatEH
         3DynZcEX2q6bw==
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E . McKenney" <paulmck@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 1/3] rcu: Fix expedited GP polling against UP/no-preempt environment
Date:   Mon, 14 Mar 2022 14:37:36 +0100
Message-Id: <20220314133738.269522-2-frederic@kernel.org>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20220314133738.269522-1-frederic@kernel.org>
References: <20220314133738.269522-1-frederic@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

synchronize_rcu_expedited() has an early return condition: if the
current CPU is the only one online and the kernel doesn't run in
preemption mode, the current assumed quiescent state is worth a grace
period.

However the expedited grace period polling caller of
synchronize_rcu_expedited() takes a GP sequence snapshot and expects it
to complete by the end of the synchronize_rcu_expedited() call. Yet if
synchronize_rcu_expedited() relies on the above described UP/no-preempt
early return, the grace period sequence won't move and may cause
an expedited grace period polling stall.

Fix this with treating polling differently while calling
synchronize_rcu_expedited() and ignore the UP-no-preempt optimization
in this case.

Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
---
 kernel/rcu/tree_exp.h | 57 ++++++++++++++++++++++++++-----------------
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index d5f30085b0cf..3d8216ced93e 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -794,27 +794,14 @@ static int rcu_print_task_exp_stall(struct rcu_node *rnp)
 
 #endif /* #else #ifdef CONFIG_PREEMPT_RCU */
 
-/**
- * synchronize_rcu_expedited - Brute-force RCU grace period
- *
- * Wait for an RCU grace period, but expedite it.  The basic idea is to
- * IPI all non-idle non-nohz online CPUs.  The IPI handler checks whether
- * the CPU is in an RCU critical section, and if so, it sets a flag that
- * causes the outermost rcu_read_unlock() to report the quiescent state
- * for RCU-preempt or asks the scheduler for help for RCU-sched.  On the
- * other hand, if the CPU is not in an RCU read-side critical section,
- * the IPI handler reports the quiescent state immediately.
- *
- * Although this is a great improvement over previous expedited
- * implementations, it is still unfriendly to real-time workloads, so is
- * thus not recommended for any sort of common-case code.  In fact, if
- * you are using synchronize_rcu_expedited() in a loop, please restructure
- * your code to batch your updates, and then use a single synchronize_rcu()
- * instead.
- *
- * This has the same semantics as (but is more brutal than) synchronize_rcu().
+/*
+ * Start and wait for an expedited grace period completion.
+ * If it happens to be called by polling functions (@polling = true),
+ * there is no possible early return in UP no-preempt mode because
+ * the callers are waiting for an actual given sequence snapshot to start
+ * and end.
  */
-void synchronize_rcu_expedited(void)
+static void __synchronize_rcu_expedited(bool polling)
 {
 	bool boottime = (rcu_scheduler_active == RCU_SCHEDULER_INIT);
 	struct rcu_exp_work rew;
@@ -827,7 +814,7 @@ void synchronize_rcu_expedited(void)
 			 "Illegal synchronize_rcu_expedited() in RCU read-side critical section");
 
 	/* Is the state is such that the call is a grace period? */
-	if (rcu_blocking_is_gp())
+	if (rcu_blocking_is_gp() && !polling)
 		return;
 
 	/* If expedited grace periods are prohibited, fall back to normal. */
@@ -863,6 +850,32 @@ void synchronize_rcu_expedited(void)
 
 	if (likely(!boottime))
 		destroy_work_on_stack(&rew.rew_work);
+
+}
+
+/**
+ * synchronize_rcu_expedited - Brute-force RCU grace period
+ *
+ * Wait for an RCU grace period, but expedite it.  The basic idea is to
+ * IPI all non-idle non-nohz online CPUs.  The IPI handler checks whether
+ * the CPU is in an RCU critical section, and if so, it sets a flag that
+ * causes the outermost rcu_read_unlock() to report the quiescent state
+ * for RCU-preempt or asks the scheduler for help for RCU-sched.  On the
+ * other hand, if the CPU is not in an RCU read-side critical section,
+ * the IPI handler reports the quiescent state immediately.
+ *
+ * Although this is a great improvement over previous expedited
+ * implementations, it is still unfriendly to real-time workloads, so is
+ * thus not recommended for any sort of common-case code.  In fact, if
+ * you are using synchronize_rcu_expedited() in a loop, please restructure
+ * your code to batch your updates, and then use a single synchronize_rcu()
+ * instead.
+ *
+ * This has the same semantics as (but is more brutal than) synchronize_rcu().
+ */
+void synchronize_rcu_expedited(void)
+{
+	__synchronize_rcu_expedited(false);
 }
 EXPORT_SYMBOL_GPL(synchronize_rcu_expedited);
 
@@ -903,7 +916,7 @@ static void sync_rcu_do_polled_gp(struct work_struct *wp)
 	if (s & 0x1)
 		return;
 	while (!sync_exp_work_done(s))
-		synchronize_rcu_expedited();
+		__synchronize_rcu_expedited(true);
 	raw_spin_lock_irqsave(&rnp->exp_poll_lock, flags);
 	s = rnp->exp_seq_poll_rq;
 	if (!(s & 0x1) && !sync_exp_work_done(s))
-- 
2.25.1


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 36609C433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 13:38:10 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S241894AbiCNNjR (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 09:39:17 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33076 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S241387AbiCNNjG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 09:39:06 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FD152AFD
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 06:37:54 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id D65F261188
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:37:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 364F2C340EC;
        Mon, 14 Mar 2022 13:37:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647265073;
        bh=Xewr86FT1fxMXD/lR5Uk6hSR4R6PnTnxz6+DRYq4q9Q=;
        h=From:To:Cc:Subject:Date:From;
        b=DztILwG16Y+xQGFHYcMh6Dd47J05+4UC61DIPOHiT+8V/xB0cVScURQGIXu5qxhe7
         beOMtD160iKkmUG7T3mGHWCCqkommUH7y6zRdL1GpvcUMt6SlZT6cnjmTZjHB2Zdc4
         Or1sgZKCxDVQuL0qC2HtPUwOZLu+ymfmN7lrXtnrPjdKqmEGtgHiHNCL6XqBGchDhM
         PZtd+x7cypyW/o4rgjF0apr1A8KO5L70R+Ytbpg7ydc/wUIqCkQ90Boahl9QM8E0el
         Z8L9SKrEWLf5HB3o6JGA3/F4anDXtf+fHf8HyEYSuuoaiyTnhOtN791aJNOe3IprkO
         nE/rL8zJl0sCQ==
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E . McKenney" <paulmck@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes
Date:   Mon, 14 Mar 2022 14:37:35 +0100
Message-Id: <20220314133738.269522-1-frederic@kernel.org>
X-Mailer: git-send-email 2.25.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


A few fixes especially for expedited GP polling causing a stall on TREE07,
as reported by Paul.

We may still want to optimize start_poll_synchronize_rcu_expedited() on
UP-no-preempt but I think Paul may be implying this while doing other
fixes.

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
	rcu/dev

HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096

Thanks,
	Frederic
---

Frederic Weisbecker (2):
      rcu: Fix expedited GP polling against UP/no-preempt environment
      rcu: Fix preemption mode check on synchronize_rcu[_expedited]()

Valentin Schneider (1):
      preempt/dynamic: Introduce preempt mode accessors


 include/linux/sched.h | 16 +++++++++++++++
 kernel/rcu/tree.c     |  2 +-
 kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
 kernel/sched/core.c   | 11 ++++++++++
 4 files changed, 63 insertions(+), 23 deletions(-)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 1CB32C433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 13:38:14 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S241896AbiCNNjV (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 09:39:21 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33370 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S241863AbiCNNjO (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 09:39:14 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 498FC1119
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 06:38:00 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by ams.source.kernel.org (Postfix) with ESMTPS id 64E8AB80DF4
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:37:59 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28375C340ED;
        Mon, 14 Mar 2022 13:37:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647265078;
        bh=jk6umewZFxLd1Bf2B9rzTYEamkBtxaQMtyRXWqXjK5A=;
        h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
        b=TKfpqy3ZScfBv4im+6QkVJ2j+hVA+h1uU3wriYMhuXUNZBxFRLWsePk0v1wZusbnX
         0q0YFvXFwecwBCtTmJgWZOI/SsubvaBd5lpApSyErtV9tP4PGG7a4TDjz49QtWuZIG
         WzDJ1zmlXqWunGCdlDeo5jVbKjuOFv/52iSS+mI2uvuw6VFIvabFzglHiDiGoNyzoX
         tBnMMLWEETg3yI6TGrSEgXXTnl1ml10/7SXJfsSi27mTSvsbQ3Er0uODB5rSQrxEWr
         UHZgJEHjrJWjE7kdpAlYCPUkKLweEK2KRubcDMEJIObN61Qadhg8mnyvf934CI0NQS
         i1axDfgMDsBbg==
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E . McKenney" <paulmck@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Frederic Weisbecker <frederic@kernel.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Date:   Mon, 14 Mar 2022 14:37:37 +0100
Message-Id: <20220314133738.269522-3-frederic@kernel.org>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20220314133738.269522-1-frederic@kernel.org>
References: <20220314133738.269522-1-frederic@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Valentin Schneider <valentin.schneider@arm.com>

CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
o The build-time preemption model when !PREEMPT_DYNAMIC
o The default boot-time preemption model when PREEMPT_DYNAMIC

IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
model could have been set to something else by the "preempt=foo" cmdline
parameter.

Introduce a set of helpers to determine the actual preemption mode used by
the live kernel.

Suggested-by: Marco Elver <elver@google.com>
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
---
 include/linux/sched.h | 16 ++++++++++++++++
 kernel/sched/core.c   | 11 +++++++++++
 2 files changed, 27 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 508b91d57470..d348e886e4d0 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
 #endif
 }
 
+#ifdef CONFIG_PREEMPT_DYNAMIC
+
+extern bool preempt_mode_none(void);
+extern bool preempt_mode_voluntary(void);
+extern bool preempt_mode_full(void);
+
+#else
+
+#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
+#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
+#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
+
+#endif
+
+#define preempt_mode_rt() IS_ENABLED(CONFIG_PREEMPT_RT)
+
 /*
  * Does a critical section need to be broken due to another
  * task waiting?: (technically does not depend on CONFIG_PREEMPTION,
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2e4ae00e52d1..6e5c8f0f874a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6684,6 +6684,17 @@ static void __init preempt_dynamic_init(void)
 	}
 }
 
+#define PREEMPT_MODE_ACCESSOR(mode) \
+	bool preempt_mode_##mode(void)						 \
+	{									 \
+		WARN_ON_ONCE(preempt_dynamic_mode == preempt_dynamic_undefined); \
+		return preempt_dynamic_mode == preempt_dynamic_##mode;		 \
+	}
+
+PREEMPT_MODE_ACCESSOR(none)
+PREEMPT_MODE_ACCESSOR(voluntary)
+PREEMPT_MODE_ACCESSOR(full)
+
 #else /* !CONFIG_PREEMPT_DYNAMIC */
 
 static inline void preempt_dynamic_init(void) { }
-- 
2.25.1


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 15C2DC433FE
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 13:38:16 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S241946AbiCNNjY (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 09:39:24 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33372 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S241865AbiCNNjO (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 09:39:14 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 359ADBC2D
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 06:38:02 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 394676118A
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:38:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AC3EC340F4;
        Mon, 14 Mar 2022 13:37:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647265080;
        bh=nF/6Lmz1r80SPWKXpwqXTgYh6Kwp/g/JtR3krTnNLFA=;
        h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
        b=kMt8EzGg6jjebnIXApidbamvN96dj89DXDxybsVMYWVpADdfqZbMgK0L+NMXH6ljc
         OnNS/oOBBYEsOrwFaa4cJ9hMH+TJioRwBbSCvL7CSdNyAVPS60mFZ2gykQhicQDPhr
         vRJ68rfOoJs1ItVfSLXQCSDfefnMzthgHhsuQtil8owAw2MFLchrEhDbzS5zC+0Efb
         qe1PBnzYW4TTqkEQzIASN/T6X5STNDdu9xRev2pnakFlHYzFBHRM5p/4dOuwxn7GA+
         ZXh6mdpwVeS4V0sAkfw0MVr5rMDxnoIrYhoDbc+ZuddUqj5VW4H95khNFu39k2PcqK
         CcxeH9K2aE2Mw==
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E . McKenney" <paulmck@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 3/3] rcu: Fix preemption mode check on synchronize_rcu[_expedited]()
Date:   Mon, 14 Mar 2022 14:37:38 +0100
Message-Id: <20220314133738.269522-4-frederic@kernel.org>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20220314133738.269522-1-frederic@kernel.org>
References: <20220314133738.269522-1-frederic@kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

An early check on synchronize_rcu[_expedited]() tries to determine if
the current CPU is in UP mode on an SMP no-preempt kernel, in which case
there is no need to start a grace period since the current assumed
quiescent state is all we need.

However the preemption mode doesn't take into account the boot selected
preemption mode under CONFIG_PREEMPT_DYNAMIC=y, missing a possible
early return if the running flavour is "none" or "voluntary".

Use the shiny new preempt mode accessors to fix this.

Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Cc: Valentin Schneider <valentin.schneider@arm.com>
---
 kernel/rcu/tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d2db709f83d9..8fe2f9843139 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3769,7 +3769,7 @@ static int rcu_blocking_is_gp(void)
 {
 	int ret;
 
-	if (IS_ENABLED(CONFIG_PREEMPTION))
+	if (preempt_mode_full() || preempt_mode_rt())
 		return rcu_scheduler_active == RCU_SCHEDULER_INACTIVE;
 	might_sleep();  /* Check for RCU read-side critical section. */
 	preempt_disable();
-- 
2.25.1


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 29AAFC433F5
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 14:45:23 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S240364AbiCNOqb (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 10:46:31 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56212 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229983AbiCNOq1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 10:46:27 -0400
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E388336161
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 07:45:16 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id e186so31198969ybc.7
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 07:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=eHOFQ6OeVmD5xAvxpdkiIICSQ9CsKQewCdMWT4MvmNM=;
        b=kJ2uFEbx/7+tJLn5CVdvf9BPKnzVRSwuYgvF7viFcSPIUz7HUSA1mNd1ZM1h2sHaIM
         PRb5ABgceN5cePC4kA4HLqxKxF07gHa1kwZcrH/kiFPVMlCvXQE0pJ7porGFuohzhEAC
         KMa9cCAOMaJRNI4Tt+KhUuBnIjCjHBe7i3Y8GCzwaSmx2oenNP7ygHFRwM0M7WPmQvVf
         788+H8YLDF+McFmOhGYp8rHyhQG2PWJxOzHOHO2Vv6/EgLEB1s6MxIPog7GL6mpVW8eT
         oOFvfCC8tv6RUGXESVkTiyCA8yiVF7wg691tbs2LBPCEmzU5YnLqbXCkPz1oq6rv+hF9
         7Erg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=eHOFQ6OeVmD5xAvxpdkiIICSQ9CsKQewCdMWT4MvmNM=;
        b=gHZWPLWDFaAIV3oejMqjRkFOraoNIFuu9EJHFI4jqt8ZsH+N4FTpz2LBjcX9VS1RtD
         YRZqeDEpALITR4aJydkgPm9h+hw8fKoN+KgX6uVxirWJ3ClMBd87qVgTcyqoIKg9tznG
         XpoVD0a3wtkI8dJfy1j6mBOsvis1aTbG+qqm7KL6pGQ1IKg0sStlAUb+2eTtgX94K7bS
         jhvBYR0c2hAX1wwiSxZTRU1oGUzJrndw3sdqc4nwGuckrkeAWMo3M0OQaY6oHkGGIbvp
         2RC9MlffKxPk7j9db8AZ9fDJ05rlM4mVTERmVVcBpaqYGLqWeA7JM4/2ApM3zvnBbMse
         zVqQ==
X-Gm-Message-State: AOAM530NCF43H//fOzWDwtRAKo2PyxhvaJjl7Xz8ZGA3VyuGHFhh7bS0
        Xi4KcefE235J7qPAjc1FkWZPqntxGQIFhtdRHW6Hwg==
X-Google-Smtp-Source: ABdhPJymjMuY2O/Ot9G/D3+o0FONpz7ABu4KFyvOcryH1Xdx2fEN383eY9Hdw++IOrTPgNoOwBMa7cVOlHHRcrcwAT0=
X-Received: by 2002:a25:d50c:0:b0:627:660c:1874 with SMTP id
 r12-20020a25d50c000000b00627660c1874mr17976243ybe.625.1647269115342; Mon, 14
 Mar 2022 07:45:15 -0700 (PDT)
MIME-Version: 1.0
References: <20220314133738.269522-1-frederic@kernel.org> <20220314133738.269522-3-frederic@kernel.org>
In-Reply-To: <20220314133738.269522-3-frederic@kernel.org>
From:   Marco Elver <elver@google.com>
Date:   Mon, 14 Mar 2022 15:44:39 +0100
Message-ID: <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     "Paul E . McKenney" <paulmck@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 14 Mar 2022 at 14:37, Frederic Weisbecker <frederic@kernel.org> wrote:
>
> From: Valentin Schneider <valentin.schneider@arm.com>
>
> CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
> o The build-time preemption model when !PREEMPT_DYNAMIC
> o The default boot-time preemption model when PREEMPT_DYNAMIC
>
> IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
> model could have been set to something else by the "preempt=foo" cmdline
> parameter.
>
> Introduce a set of helpers to determine the actual preemption mode used by
> the live kernel.
>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> ---
>  include/linux/sched.h | 16 ++++++++++++++++
>  kernel/sched/core.c   | 11 +++++++++++
>  2 files changed, 27 insertions(+)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 508b91d57470..d348e886e4d0 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
>  #endif
>  }
>
> +#ifdef CONFIG_PREEMPT_DYNAMIC
> +
> +extern bool preempt_mode_none(void);
> +extern bool preempt_mode_voluntary(void);
> +extern bool preempt_mode_full(void);
> +
> +#else
> +
> +#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
> +#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
> +#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
> +

Shame this was somehow forgotten.
There was a v3 of this patch that fixed a bunch of things (e.g. making
these proper functions so all builds error if accidentally used in
#if).

https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/

Is it also possible to take all the rest of that series (all 4
patches) from Valentin?

Thanks,
-- Marco

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 90A91C433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 20:07:18 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S237668AbiCNUI1 (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 16:08:27 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44524 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S244964AbiCNUHw (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 16:07:52 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 889C240A28
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:06:42 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 1449561243
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 20:06:42 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C5ACC340E9;
        Mon, 14 Mar 2022 20:06:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647288401;
        bh=DOHt3LCYvGZ+M+llhcPXpvszVirNj9b7Vx1WQLAkF94=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=AanFG3WOTPvNoEiZcNP6OIPA2FuwI8mElPD56f2ouM3bwPsY2Dr4XPLp6qFsIunUL
         Ox9ujc1OPKbG/whDy+/E1JxWHcUxzlTWO/Ehmvkw1zEkIlnZOq6wDnDOGTX0YizyOs
         OVUzjsz4Av7yQr7vyNMLcRPCbqaFMlzw1Er2cJRycFsOWJStqEVr2XW9e3sOH/PEPV
         hjCNQV6uxQ8020xp3h/Vo8UYB51oBeoTOxerq/5c1bQQWPZ8XLCXSuRvRFi9V6QHd0
         oMo1U50MECs6ZWvioOPQpPImwP9urRn9XNsygUo0E0hYyd4v/7etHfW7ael0Aq/9ng
         3qe5ISqwZOkoQ==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id 18CC85C023F; Mon, 14 Mar 2022 13:06:41 -0700 (PDT)
Date:   Mon, 14 Mar 2022 13:06:41 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Marco Elver <elver@google.com>
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Message-ID: <20220314200641.GV4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> On Mon, 14 Mar 2022 at 14:37, Frederic Weisbecker <frederic@kernel.org> wrote:
> >
> > From: Valentin Schneider <valentin.schneider@arm.com>
> >
> > CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
> > o The build-time preemption model when !PREEMPT_DYNAMIC
> > o The default boot-time preemption model when PREEMPT_DYNAMIC
> >
> > IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
> > model could have been set to something else by the "preempt=foo" cmdline
> > parameter.
> >
> > Introduce a set of helpers to determine the actual preemption mode used by
> > the live kernel.
> >
> > Suggested-by: Marco Elver <elver@google.com>
> > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
> > Cc: Joel Fernandes <joel@joelfernandes.org>
> > Cc: Boqun Feng <boqun.feng@gmail.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> > ---
> >  include/linux/sched.h | 16 ++++++++++++++++
> >  kernel/sched/core.c   | 11 +++++++++++
> >  2 files changed, 27 insertions(+)
> >
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 508b91d57470..d348e886e4d0 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
> >  #endif
> >  }
> >
> > +#ifdef CONFIG_PREEMPT_DYNAMIC
> > +
> > +extern bool preempt_mode_none(void);
> > +extern bool preempt_mode_voluntary(void);
> > +extern bool preempt_mode_full(void);
> > +
> > +#else
> > +
> > +#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
> > +#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
> > +#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
> > +
> 
> Shame this was somehow forgotten.
> There was a v3 of this patch that fixed a bunch of things (e.g. making
> these proper functions so all builds error if accidentally used in
> #if).
> 
> https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> 
> Is it also possible to take all the rest of that series (all 4
> patches) from Valentin?

Me, I am assuming that #2/3 is an experimental test so that I am able
to easily whack this series over the head with rcutorture.  ;-)

							Thanx, Paul

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 5AA4DC433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 20:26:20 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S245002AbiCNU12 (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 16:27:28 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56866 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S240478AbiCNU11 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 16:27:27 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06A573917E
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:26:16 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by ams.source.kernel.org (Postfix) with ESMTPS id 80387B80FE7
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 20:26:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14461C340E9;
        Mon, 14 Mar 2022 20:26:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647289571;
        bh=9CS29+T32I+TMcpS8styzHO75+JE2E1H4hCtaXxugCo=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=Mn55mgnVDnSmww/J8Y1UBj81s5MHWoXrfl7RpaF1LZjVgNAaWNsomIdpdipfI/xyb
         /ZUmzyto56XCK21Q/XSP4j+s6qosm5nuH8IssEhYg7TqUqrz59ku2mq7By3oF2vaAm
         NPZLKlf1Qn4YDyfuz8nC7DCUqo8eTbr6BuWOnZp//C565POnsO/vkn89LSmkm1B3sm
         RApIfb/H11md0Edk/j5lkHNREhtpauYb6rOoWk1Zlk7fuO5v/omL2bgoYfje/lKHa8
         z6YzKgGzHy26zI93Fmik4rFYqpjOGoJTxWvTdDkZpYJMnYZxD9NXTgNPTBcym6IsnD
         nYiN/9Y7KkrVw==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id ACA5E5C4162; Mon, 14 Mar 2022 13:26:10 -0700 (PDT)
Date:   Mon, 14 Mar 2022 13:26:10 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes
Message-ID: <20220314202610.GW4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220314133738.269522-1-frederic@kernel.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 02:37:35PM +0100, Frederic Weisbecker wrote:
> 
> A few fixes especially for expedited GP polling causing a stall on TREE07,
> as reported by Paul.
> 
> We may still want to optimize start_poll_synchronize_rcu_expedited() on
> UP-no-preempt but I think Paul may be implying this while doing other
> fixes.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> 	rcu/dev
> 
> HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096
> 
> Thanks,
> 	Frederic

I have pulled these in for review and testing, thank you!!!  I have
started a ~90-minute test and will let you know how that goes.

> ---
> 
> Frederic Weisbecker (2):
>       rcu: Fix expedited GP polling against UP/no-preempt environment

I have some concerns with this one due to the fact that it acquires locks
in cases where the old code would not.  (I did have problems with this
in both recent SRCU changes and the normal-grace-period counterpart to
this series.)

But let's see what rcutorture and kbuild test robot think about it.

>       rcu: Fix preemption mode check on synchronize_rcu[_expedited]()

This one looks good.

> Valentin Schneider (1):
>       preempt/dynamic: Introduce preempt mode accessors

I am guessing that this one is a compact placeholder for my convenience
(in which case thank you!).  I will be marking it "EXP" on my next rebase.

							Thanx, Paul

>  include/linux/sched.h | 16 +++++++++++++++
>  kernel/rcu/tree.c     |  2 +-
>  kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
>  kernel/sched/core.c   | 11 ++++++++++
>  4 files changed, 63 insertions(+), 23 deletions(-)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id BB9EBC433F5
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 20:35:07 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S239124AbiCNUgQ (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 16:36:16 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48342 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S231499AbiCNUgP (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 16:36:15 -0400
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BBF0329B0
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:35:03 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id v130so33157389ybe.13
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 13:35:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20210112;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=cEwC2oWm7E+TdYn9pjXIfdcT9lJnbB3JTmkCY2AgKHQ=;
        b=Q2+LiluU9906bLSTT9h7OPB+28HX9RJk5Fgi3kilfKrvbwjlosf57o8SIG6ZWFvzqQ
         tVFolIcruqmBocumtKnTmn4WMd8G/hQ79tHr9nt+/kouRiR+yYoAXB0vr9zZU8HtwBff
         YqFQqVQm95SK6Hc7+E7yFkuasGlFrhn8zOjLyQX+FNgupbJakVqrVyagedXH9lewlB7S
         9x/gXxulgTdQTzapN/u8sFp8z//hSXcJIeTQEMXiqjmqoIvJS6ziQOFHYr0oMWZHg0NR
         1uA1UCpXNAZQc4OsgyPSyF7EuPj/krnO3JxvDZq+d4HGyT4u9+qOYoZ01rb46QhYL8Ie
         afvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=cEwC2oWm7E+TdYn9pjXIfdcT9lJnbB3JTmkCY2AgKHQ=;
        b=Roynn/GJz2VaFOMqM5m1GQcEhJqBxuA5p34guLRKUvwnybBsqvUjWzH0TNiQ0m1yEB
         CpsSjixbBmsz37g866inI7BGBjjOhxrqz2rAG/WvDqLxobnbq/YF6EZfeBLSiHcw7ycx
         bISH9GE7hO95ZKUsXyRdJOtcSJrkpDWOU29fIadevP53cpVC0UOZh73kZ81vgtl06SSX
         0wkEpHAMYjRleDAGTl/dsK0q661ueQv1f+fE/mhYMUIZ1B4WQI39Prtq4VX3O6wpk/Ib
         mUVYGj+1PmRWz35kqj03/K5XEY9WTK6lHRCSmQA03o6UNktGEjt1BlC2FVkDWL9VPyoO
         Gg7A==
X-Gm-Message-State: AOAM530yNTPyeSqnXFCLGXK47q2i7qypdaLWKtk36JD1KcijXLCc8fSd
        yMKAI8Vo9RzM+iyLxTPJtFj9qDhwknCAqVpaLImU4aeesM0=
X-Google-Smtp-Source: ABdhPJzFxCOwbIwtBX8TR6abtHqC4NXg1xaPBpeedRiqRdOwsDIrT9iA/qqoJDHu/WTIhvwFdqYHiaek7j0a38LEKq0=
X-Received: by 2002:a25:d50c:0:b0:627:660c:1874 with SMTP id
 r12-20020a25d50c000000b00627660c1874mr19610951ybe.625.1647290102968; Mon, 14
 Mar 2022 13:35:02 -0700 (PDT)
MIME-Version: 1.0
References: <20220314133738.269522-1-frederic@kernel.org> <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com> <20220314200641.GV4285@paulmck-ThinkPad-P17-Gen-1>
In-Reply-To: <20220314200641.GV4285@paulmck-ThinkPad-P17-Gen-1>
From:   Marco Elver <elver@google.com>
Date:   Mon, 14 Mar 2022 21:34:26 +0100
Message-ID: <CANpmjNMsyb9aOqcvUUMLbkyHiE9ZieBigU1XqBXgtYz_O00y3g@mail.gmail.com>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
To:     paulmck@kernel.org
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 14 Mar 2022 at 21:06, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> > On Mon, 14 Mar 2022 at 14:37, Frederic Weisbecker <frederic@kernel.org> wrote:
> > >
> > > From: Valentin Schneider <valentin.schneider@arm.com>
> > >
> > > CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
> > > o The build-time preemption model when !PREEMPT_DYNAMIC
> > > o The default boot-time preemption model when PREEMPT_DYNAMIC
> > >
> > > IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
> > > model could have been set to something else by the "preempt=foo" cmdline
> > > parameter.
> > >
> > > Introduce a set of helpers to determine the actual preemption mode used by
> > > the live kernel.
> > >
> > > Suggested-by: Marco Elver <elver@google.com>
> > > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
> > > Cc: Joel Fernandes <joel@joelfernandes.org>
> > > Cc: Boqun Feng <boqun.feng@gmail.com>
> > > Cc: Peter Zijlstra <peterz@infradead.org>
> > > Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> > > ---
> > >  include/linux/sched.h | 16 ++++++++++++++++
> > >  kernel/sched/core.c   | 11 +++++++++++
> > >  2 files changed, 27 insertions(+)
> > >
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index 508b91d57470..d348e886e4d0 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
> > >  #endif
> > >  }
> > >
> > > +#ifdef CONFIG_PREEMPT_DYNAMIC
> > > +
> > > +extern bool preempt_mode_none(void);
> > > +extern bool preempt_mode_voluntary(void);
> > > +extern bool preempt_mode_full(void);
> > > +
> > > +#else
> > > +
> > > +#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
> > > +#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
> > > +#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
> > > +
> >
> > Shame this was somehow forgotten.
> > There was a v3 of this patch that fixed a bunch of things (e.g. making
> > these proper functions so all builds error if accidentally used in
> > #if).
> >
> > https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> >
> > Is it also possible to take all the rest of that series (all 4
> > patches) from Valentin?
>
> Me, I am assuming that #2/3 is an experimental test so that I am able
> to easily whack this series over the head with rcutorture.  ;-)

I might be out of the loop here. All I can add is that any issues that
are a consequence of the preempt mode accessors are only testable if
the preemption model is actually changed at runtime and AFAIK
rcutorture doesn't do that. But as noted, this patch wasn't the latest
version and there were issues with it fixed by Valentin's latest v3
(from November, but had never been picked up anywhere).

Thanks,
-- Marco

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 8C558C433EF
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 21:53:54 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S245419AbiCNVzD (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 17:55:03 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58326 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S235932AbiCNVzA (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 17:55:00 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E05B135DD0
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 14:53:49 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 274F46135E
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 21:53:49 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81EB5C340E9;
        Mon, 14 Mar 2022 21:53:48 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647294828;
        bh=QDOU3spVqdpsvf3p9pseTP+NSIdd5DYDKvSNKCwGzW4=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=B679eC4f8RA5kqmFnEQCHQP4gvmFpWWq+Ilj1vxGUuIinGAEna9umrZDACtJY6iOd
         Fa0y49+p6iqarq5CTdfwC+ujQmTVwLnh8zmLGbnMTcgdpaSm5tlOLwY5j8Rj1tQ+lf
         45SZZa9/mvqvluPaMU2MaY2jTEuiwkg15DceBXc2WAjvkA6vqRqwW/uvLYOP3rhyh6
         J0HFyVCuAlbS/G9ngim1O8a+YMB0EjwHbKLzvsPFv3briJspSjBYHfxL5zkiID/4zw
         Si4HN8j7ka2WeOIUy4ZbaXJeewovsgw8MY4T1Tx4g5dOx5RZV5GBUa3DFstbZtf2zD
         zfipzdG9XHUKg==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id 1DB075C023F; Mon, 14 Mar 2022 14:53:48 -0700 (PDT)
Date:   Mon, 14 Mar 2022 14:53:48 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Marco Elver <elver@google.com>
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Message-ID: <20220314215348.GA4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
 <20220314200641.GV4285@paulmck-ThinkPad-P17-Gen-1>
 <CANpmjNMsyb9aOqcvUUMLbkyHiE9ZieBigU1XqBXgtYz_O00y3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANpmjNMsyb9aOqcvUUMLbkyHiE9ZieBigU1XqBXgtYz_O00y3g@mail.gmail.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 09:34:26PM +0100, Marco Elver wrote:
> On Mon, 14 Mar 2022 at 21:06, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> > > On Mon, 14 Mar 2022 at 14:37, Frederic Weisbecker <frederic@kernel.org> wrote:
> > > >
> > > > From: Valentin Schneider <valentin.schneider@arm.com>
> > > >
> > > > CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
> > > > o The build-time preemption model when !PREEMPT_DYNAMIC
> > > > o The default boot-time preemption model when PREEMPT_DYNAMIC
> > > >
> > > > IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
> > > > model could have been set to something else by the "preempt=foo" cmdline
> > > > parameter.
> > > >
> > > > Introduce a set of helpers to determine the actual preemption mode used by
> > > > the live kernel.
> > > >
> > > > Suggested-by: Marco Elver <elver@google.com>
> > > > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > > Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
> > > > Cc: Joel Fernandes <joel@joelfernandes.org>
> > > > Cc: Boqun Feng <boqun.feng@gmail.com>
> > > > Cc: Peter Zijlstra <peterz@infradead.org>
> > > > Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> > > > ---
> > > >  include/linux/sched.h | 16 ++++++++++++++++
> > > >  kernel/sched/core.c   | 11 +++++++++++
> > > >  2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > index 508b91d57470..d348e886e4d0 100644
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
> > > >  #endif
> > > >  }
> > > >
> > > > +#ifdef CONFIG_PREEMPT_DYNAMIC
> > > > +
> > > > +extern bool preempt_mode_none(void);
> > > > +extern bool preempt_mode_voluntary(void);
> > > > +extern bool preempt_mode_full(void);
> > > > +
> > > > +#else
> > > > +
> > > > +#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
> > > > +#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
> > > > +#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
> > > > +
> > >
> > > Shame this was somehow forgotten.
> > > There was a v3 of this patch that fixed a bunch of things (e.g. making
> > > these proper functions so all builds error if accidentally used in
> > > #if).
> > >
> > > https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> > >
> > > Is it also possible to take all the rest of that series (all 4
> > > patches) from Valentin?
> >
> > Me, I am assuming that #2/3 is an experimental test so that I am able
> > to easily whack this series over the head with rcutorture.  ;-)
> 
> I might be out of the loop here. All I can add is that any issues that
> are a consequence of the preempt mode accessors are only testable if
> the preemption model is actually changed at runtime and AFAIK
> rcutorture doesn't do that. But as noted, this patch wasn't the latest
> version and there were issues with it fixed by Valentin's latest v3
> (from November, but had never been picked up anywhere).

I will be marking 2/3 "EXP" to prevent myself from accidentally sending
it upstream.

But longer term, maybe I should pick up Valentin's series.

This stuff is v5.19 at the earliest, so not (yet) urgent.

							Thanx, Paul

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id E0BE3C433F5
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 22:35:11 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S240755AbiCNWgU (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 18:36:20 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53786 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S237216AbiCNWgS (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 18:36:18 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46ACF30F73
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 15:35:05 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 57D8C6140C
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 22:35:05 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5BC4C340E9;
        Mon, 14 Mar 2022 22:35:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647297304;
        bh=hbsjHiLQ5g+4nDSjuI4RnOLjrnPpRYYdrxZhXbxfh3o=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=fAGJa7jO/QZRtaMpck6eVyC47pTxDnID33LYKFxdVZ70KBD8v42ysyfKAw0nX32fo
         O+JabTjjeQqKroVmhfICVTyzVTEd4n4dKAKN+BJfFw++ebJqrbA1Rx6A7W7MMpQY5i
         FrduoPAwWMvd0L0r2Hj7QCSs5TqKge4vloxnBlG39VKiygIdcQq27qABr4m39yDbvS
         U8GdSQichZyU82J5M9UdiN6upesZ8vi+357wvaSHWbMjAJplu5UTlHwLOkRE9DiBRO
         nZl+RngXipWUOkxWEwKgcfgMCtPmQKDy2mvVE2rK0P+evgNOnwgegqI585BOopjYhp
         OwhY/CHu2sp5w==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id 507E85C023F; Mon, 14 Mar 2022 15:35:04 -0700 (PDT)
Date:   Mon, 14 Mar 2022 15:35:04 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes
Message-ID: <20220314223504.GA1150279@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314202610.GW4285@paulmck-ThinkPad-P17-Gen-1>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220314202610.GW4285@paulmck-ThinkPad-P17-Gen-1>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 01:26:10PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 14, 2022 at 02:37:35PM +0100, Frederic Weisbecker wrote:
> > 
> > A few fixes especially for expedited GP polling causing a stall on TREE07,
> > as reported by Paul.
> > 
> > We may still want to optimize start_poll_synchronize_rcu_expedited() on
> > UP-no-preempt but I think Paul may be implying this while doing other
> > fixes.
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > 	rcu/dev
> > 
> > HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096
> > 
> > Thanks,
> > 	Frederic
> 
> I have pulled these in for review and testing, thank you!!!  I have
> started a ~90-minute test and will let you know how that goes.

And TREE05 doesn't like this much.  I get too-short grace periods.
TREE05 is unusual in being the one with the kernel build with
CONFIG_PREEMPT_NONE=y but also with CONFIG_PREEMPT_DYNAMIC=n.

Running tests of the commits individually.

							Thanx, Paul

> > ---
> > 
> > Frederic Weisbecker (2):
> >       rcu: Fix expedited GP polling against UP/no-preempt environment
> 
> I have some concerns with this one due to the fact that it acquires locks
> in cases where the old code would not.  (I did have problems with this
> in both recent SRCU changes and the normal-grace-period counterpart to
> this series.)
> 
> But let's see what rcutorture and kbuild test robot think about it.
> 
> >       rcu: Fix preemption mode check on synchronize_rcu[_expedited]()
> 
> This one looks good.
> 
> > Valentin Schneider (1):
> >       preempt/dynamic: Introduce preempt mode accessors
> 
> I am guessing that this one is a compact placeholder for my convenience
> (in which case thank you!).  I will be marking it "EXP" on my next rebase.
> 
> 							Thanx, Paul
> 
> >  include/linux/sched.h | 16 +++++++++++++++
> >  kernel/rcu/tree.c     |  2 +-
> >  kernel/rcu/tree_exp.h | 57 +++++++++++++++++++++++++++++++--------------------
> >  kernel/sched/core.c   | 11 ++++++++++
> >  4 files changed, 63 insertions(+), 23 deletions(-)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 6920CC433F5
	for <linux-kernel@archiver.kernel.org>; Mon, 14 Mar 2022 22:50:17 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S245153AbiCNWv0 (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 14 Mar 2022 18:51:26 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58398 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229751AbiCNWvX (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 14 Mar 2022 18:51:23 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38DCF12AEA
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 15:50:12 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 3302B6145D
        for <linux-kernel@vger.kernel.org>; Mon, 14 Mar 2022 22:50:12 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A39BC340E9;
        Mon, 14 Mar 2022 22:50:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647298211;
        bh=yU6R9YbJUvwfWtUyD7sqbv7BgTnIuuJOKpA58IceBKk=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=a7FzeXaDkLXX7FkVlUTsQXve+HwRAfWZfhZaliDi+/igBX5ygYOQe1Md9z7wSNzK0
         yqkbsDBWouFyeywabPn9nDKhxPhQLyy+5Ed6pQfSXH/zD9DuY3QYVr4J7nDFCmeB01
         cjPUtR1dP5mp4NG4XXQdcgUIU/8GeDJrc6OodpmXlHxvPj5ipb1Oes3JkqbPMIHDX4
         u20fvv+n7+G5m/V9up72sEb/RpA5BLpP4Augcv4HXALLeDsdIL9Rht8xp0THLpqhKH
         o1/VHnreG8cPQg+7V5l3DuSeG1/ks6esQSR6zO2GhCN7R01DtT4VcGGBSe1AJfwjnp
         wnnODqal+zlCw==
Date:   Mon, 14 Mar 2022 23:50:08 +0100
From:   Frederic Weisbecker <frederic@kernel.org>
To:     Marco Elver <elver@google.com>
Cc:     paulmck@kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Message-ID: <20220314225008.GB274290@lothringen>
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
 <20220314200641.GV4285@paulmck-ThinkPad-P17-Gen-1>
 <CANpmjNMsyb9aOqcvUUMLbkyHiE9ZieBigU1XqBXgtYz_O00y3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANpmjNMsyb9aOqcvUUMLbkyHiE9ZieBigU1XqBXgtYz_O00y3g@mail.gmail.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 09:34:26PM +0100, Marco Elver wrote:
> On Mon, 14 Mar 2022 at 21:06, Paul E. McKenney <paulmck@kernel.org> wrote:
> >
> > On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> > > On Mon, 14 Mar 2022 at 14:37, Frederic Weisbecker <frederic@kernel.org> wrote:
> > > >
> > > > From: Valentin Schneider <valentin.schneider@arm.com>
> > > >
> > > > CONFIG_PREEMPT{_NONE, _VOLUNTARY} designate either:
> > > > o The build-time preemption model when !PREEMPT_DYNAMIC
> > > > o The default boot-time preemption model when PREEMPT_DYNAMIC
> > > >
> > > > IOW, using those on PREEMPT_DYNAMIC kernels is meaningless - the actual
> > > > model could have been set to something else by the "preempt=foo" cmdline
> > > > parameter.
> > > >
> > > > Introduce a set of helpers to determine the actual preemption mode used by
> > > > the live kernel.
> > > >
> > > > Suggested-by: Marco Elver <elver@google.com>
> > > > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > > Cc: Uladzislau Rezki <uladzislau.rezki@sony.com>
> > > > Cc: Joel Fernandes <joel@joelfernandes.org>
> > > > Cc: Boqun Feng <boqun.feng@gmail.com>
> > > > Cc: Peter Zijlstra <peterz@infradead.org>
> > > > Cc: Neeraj Upadhyay <quic_neeraju@quicinc.com>
> > > > ---
> > > >  include/linux/sched.h | 16 ++++++++++++++++
> > > >  kernel/sched/core.c   | 11 +++++++++++
> > > >  2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > index 508b91d57470..d348e886e4d0 100644
> > > > --- a/include/linux/sched.h
> > > > +++ b/include/linux/sched.h
> > > > @@ -2096,6 +2096,22 @@ static inline void cond_resched_rcu(void)
> > > >  #endif
> > > >  }
> > > >
> > > > +#ifdef CONFIG_PREEMPT_DYNAMIC
> > > > +
> > > > +extern bool preempt_mode_none(void);
> > > > +extern bool preempt_mode_voluntary(void);
> > > > +extern bool preempt_mode_full(void);
> > > > +
> > > > +#else
> > > > +
> > > > +#define preempt_mode_none() IS_ENABLED(CONFIG_PREEMPT_NONE)
> > > > +#define preempt_mode_voluntary() IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
> > > > +#define preempt_mode_full() IS_ENABLED(CONFIG_PREEMPT)
> > > > +
> > >
> > > Shame this was somehow forgotten.
> > > There was a v3 of this patch that fixed a bunch of things (e.g. making
> > > these proper functions so all builds error if accidentally used in
> > > #if).
> > >
> > > https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> > >
> > > Is it also possible to take all the rest of that series (all 4
> > > patches) from Valentin?
> >
> > Me, I am assuming that #2/3 is an experimental test so that I am able
> > to easily whack this series over the head with rcutorture.  ;-)
> 
> I might be out of the loop here. All I can add is that any issues that
> are a consequence of the preempt mode accessors are only testable if
> the preemption model is actually changed at runtime and AFAIK
> rcutorture doesn't do that. But as noted, this patch wasn't the latest
> version and there were issues with it fixed by Valentin's latest v3
> (from November, but had never been picked up anywhere).

Thanks for the reminder, the patchset indeed got forgotten somewhow.
If necessary I'll resend it.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 9876BC433F5
	for <linux-kernel@archiver.kernel.org>; Tue, 15 Mar 2022 10:49:24 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1347562AbiCOKud (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 15 Mar 2022 06:50:33 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35138 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1348707AbiCOKtt (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Mar 2022 06:49:49 -0400
Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 89FF6275DC
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 03:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
        d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
        References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
        Content-Transfer-Encoding:Content-ID:Content-Description;
        bh=bzjITRLip76YCCbU9LHjuc8S4NeB67qbdOXzTfdXcto=; b=Cxx6XNEYTxhqe4+MqJsYyCeMk0
        FroCDWr4W7byDJSLf+2svEmBPf/wTYIWBX+aOQgdiY4dOm0Kbe/Yjn54vj3/3wpA1KoECbZB7sUkl
        RVSlVrSaH/FdDQ5ZRcGlXuxTuCnC1IZ6qQyofWa3q6rkHMXiryqzJGer8W9Zwl+GZYGmHdpc+2fDT
        PSZJMFvHeDBWshJ3kcb3CK1nqetYp+2bCyPhKGsgqXdQBKR3JiytaRppRSYdzhzdij/v5h3HXlTzd
        74uDZaER6Wlymb3bgZ/X/VRtF3rfT8ixfIu83jzrjy1UsFhjStz/bEWmZ5BuSd+wznOL1uCsuypTQ
        EOGc0WvA==;
Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net)
        by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux))
        id 1nU4ix-004x0x-Q0; Tue, 15 Mar 2022 10:48:19 +0000
Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000)
        id C38C298620D; Tue, 15 Mar 2022 11:48:17 +0100 (CET)
Date:   Tue, 15 Mar 2022 11:48:17 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Marco Elver <elver@google.com>
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        "Paul E . McKenney" <paulmck@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Message-ID: <20220315104817.GE8939@worktop.programming.kicks-ass.net>
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> 
> Is it also possible to take all the rest of that series (all 4
> patches) from Valentin?

I'll go stick the remaining 3 patches from Valentin in sched/core, they
seem to still apply without issue.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id A5E7EC433EF
	for <linux-kernel@archiver.kernel.org>; Tue, 15 Mar 2022 15:11:59 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1348986AbiCOPNK (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 15 Mar 2022 11:13:10 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46144 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S234857AbiCOPNJ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Mar 2022 11:13:09 -0400
Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EFC113F10
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 08:11:55 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by ams.source.kernel.org (Postfix) with ESMTPS id 3D86DB81731
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 15:11:54 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5003C340E8;
        Tue, 15 Mar 2022 15:11:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647357112;
        bh=tmAYCIaKsF0LUd/bmZ182eQrbvS+ccIG9Pcjgkbdn9s=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=RvIKUhyU5dVPz0CZVC34DyE5eEP6wJS7GQ2CftzkIgKqU94K8hfp8HUO62kJTfG0s
         qvAyAjjefh9gyqz1EUITEidFBUsSynD7icsMGHaE5GehLv5dOFC6LZyfXfS0bkk+Fc
         rFB+v0oNM4hKDHs4r6zC7B+hS2dhzJma434yiW1h4FIapkQtMVsxUEMg0XbrSO7gxw
         MGlfDYCrCQzZfmrQ5zM3eQDn7sPd3E5LLUkuCLfBwVlrWAO/sW+NwQx7+fJ6sUgAQ0
         5GNNzCSP4lY3dzct2thsWaFA38Ho6WBV9gnyYJST972ggUPtnRLvaf4N4+i+LCvo9N
         P5g2t0AdszODg==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id 795E95C417C; Tue, 15 Mar 2022 08:11:52 -0700 (PDT)
Date:   Tue, 15 Mar 2022 08:11:52 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Marco Elver <elver@google.com>,
        Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/3] preempt/dynamic: Introduce preempt mode accessors
Message-ID: <20220315151152.GC4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314133738.269522-3-frederic@kernel.org>
 <CANpmjNPqY65ZYLFukgp779pHbiRH05yns+G7Z36QdWwrQp1WOQ@mail.gmail.com>
 <20220315104817.GE8939@worktop.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220315104817.GE8939@worktop.programming.kicks-ass.net>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 15, 2022 at 11:48:17AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 14, 2022 at 03:44:39PM +0100, Marco Elver wrote:
> > https://lore.kernel.org/lkml/20211112185203.280040-3-valentin.schneider@arm.com/
> > 
> > Is it also possible to take all the rest of that series (all 4
> > patches) from Valentin?
> 
> I'll go stick the remaining 3 patches from Valentin in sched/core, they
> seem to still apply without issue.

If testing goes well, are you planning to push into the upcoming
merge window?  (I won't be pushing until the v5.19 merge window at
the earliest.)

Either way, just please let me know!

							Thanx, Paul

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id BAFEEC433EF
	for <linux-kernel@archiver.kernel.org>; Tue, 15 Mar 2022 15:52:39 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1344405AbiCOPxu (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 15 Mar 2022 11:53:50 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44740 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1349874AbiCOPxo (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Mar 2022 11:53:44 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A38B55BD7
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 08:52:32 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id 42FDC6134E
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 15:52:30 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19281C340ED;
        Tue, 15 Mar 2022 15:52:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647359549;
        bh=zjDOtndMSP12811nc1wYenpXv0yI+HChpWPOg9L3V4g=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=eObWNAZfYH1Ruq+q76YTgA+6fMA1ki9pMImj9pPbmw54sj/hhV9uEy+A/Ud9FebQc
         jgevnmxaNXaYHKalS/Osr9qvV6Eh0+b6boP8ujbBXX8gjzmzscqFFwIDZEJ5iprmxX
         TXk4BLtxZa+MtoeKY7pbmaV3V7EnzmEoT1s+xIpFYwhn7tfDwOZdUXLm62nMpwTJQB
         EAaEIB3mtmA1gTPcpgLbHj742X4WXuMEvj0J3rmgohPxUm9aq8NqoPWq/2wN4/Z+n4
         dD2FLlnumIHwRaJtUs8PWIfC1zY2eyC1t9b7Hpakm8qWJ3a0WpGEn/6Uk75jyNr5BG
         grYKyM+lm10WQ==
Date:   Tue, 15 Mar 2022 16:52:26 +0100
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes
Message-ID: <20220315155226.GC274290@lothringen>
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314202610.GW4285@paulmck-ThinkPad-P17-Gen-1>
 <20220314223504.GA1150279@paulmck-ThinkPad-P17-Gen-1>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220314223504.GA1150279@paulmck-ThinkPad-P17-Gen-1>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 14, 2022 at 03:35:04PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 14, 2022 at 01:26:10PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 14, 2022 at 02:37:35PM +0100, Frederic Weisbecker wrote:
> > > 
> > > A few fixes especially for expedited GP polling causing a stall on TREE07,
> > > as reported by Paul.
> > > 
> > > We may still want to optimize start_poll_synchronize_rcu_expedited() on
> > > UP-no-preempt but I think Paul may be implying this while doing other
> > > fixes.
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > 	rcu/dev
> > > 
> > > HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096
> > > 
> > > Thanks,
> > > 	Frederic
> > 
> > I have pulled these in for review and testing, thank you!!!  I have
> > started a ~90-minute test and will let you know how that goes.
> 
> And TREE05 doesn't like this much.  I get too-short grace periods.
> TREE05 is unusual in being the one with the kernel build with
> CONFIG_PREEMPT_NONE=y but also with CONFIG_PREEMPT_DYNAMIC=n.
> 
> Running tests of the commits individually.

Ouch, please test the following:

---
>From f180dd5809d2c3a6343cbd13f244b7b7f110a506 Mon Sep 17 00:00:00 2001
From: Frederic Weisbecker <frederic@kernel.org>
Date: Tue, 15 Mar 2022 16:33:38 +0100
Subject: [PATCH] rcutorture: Call preempt_schedule() through static call/key

rcutorture sometimes want to trigger a random scheduler preemption call
while simulating a read delay. However a direct call to
preempt_schedule() is not desirable because it bypasses the static
call/key filter used by CONFIG_PREEMPT_DYNAMIC. This breaks the
no-preempt assumption in case the dynamic preemption mode is "none".

For example rcu_blocking_is_gp() is fooled and abbreviates grace periods
when the CPU runs in no-preempt UP mode.

Fix this with making torture_preempt_schedule() to call through
preempt dynamic static call/key.

Reported-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 include/linux/torture.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/torture.h b/include/linux/torture.h
index 63fa4196e51c..7038104463e4 100644
--- a/include/linux/torture.h
+++ b/include/linux/torture.h
@@ -118,7 +118,7 @@ void _torture_stop_kthread(char *m, struct task_struct **tp);
 	_torture_stop_kthread("Stopping " #n " task", &(tp))
 
 #ifdef CONFIG_PREEMPTION
-#define torture_preempt_schedule() preempt_schedule()
+#define torture_preempt_schedule() __preempt_schedule()
 #else
 #define torture_preempt_schedule()	do { } while (0)
 #endif
-- 
2.25.1


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id E60D3C433F5
	for <linux-kernel@archiver.kernel.org>; Tue, 15 Mar 2022 16:53:56 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1350277AbiCOQzH (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 15 Mar 2022 12:55:07 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35650 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1349326AbiCOQzG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 15 Mar 2022 12:55:06 -0400
Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EEE360C9
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 09:53:54 -0700 (PDT)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by dfw.source.kernel.org (Postfix) with ESMTPS id AE659614FC
        for <linux-kernel@vger.kernel.org>; Tue, 15 Mar 2022 16:53:53 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A512C340EE;
        Tue, 15 Mar 2022 16:53:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
        s=k20201202; t=1647363233;
        bh=BE+mZFuhWtGnpkipd8lO2jJtgDxnwN/Oe8GiIzdTzYY=;
        h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From;
        b=aADC4ZqYbiajgjWycpRCgmLc60pE8+6unA0QsIxkTpdkZ1N3S9xS9MlLay6LAK8ua
         AVf/fi1TsgToAxRac33f1eCVQt79TOGBeAN5ZJ/Xfy3i94+tlJcWSzeCmTSzLF/Vs3
         FuV9mvLLpvYHQh8A9YQb6MuhJTmQnlCVokGEXCeo4tKuv9jV7I/4uke2pFBrsZToeT
         yqEpKWZWHJnouR5UkuuXltkqXPiErC73RKlNMxagSMHyLjn+5xts+WJeXJAF2zZBR9
         sgjKdy19WRKWrKju1p5D/TGpKRT/8Hd3yTnHE7irPvRf/P6JP/TiYNOTGy6kEd0TPg
         yoyPDoA+Ol+bg==
Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000)
        id B922C5C051B; Tue, 15 Mar 2022 09:53:52 -0700 (PDT)
Date:   Tue, 15 Mar 2022 09:53:52 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Marco Elver <elver@google.com>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Uladzislau Rezki <uladzislau.rezki@sony.com>,
        Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 0/3] rcu: synchronize_rcu[_expedited]() related fixes
Message-ID: <20220315165352.GE4285@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <20220314133738.269522-1-frederic@kernel.org>
 <20220314202610.GW4285@paulmck-ThinkPad-P17-Gen-1>
 <20220314223504.GA1150279@paulmck-ThinkPad-P17-Gen-1>
 <20220315155226.GC274290@lothringen>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220315155226.GC274290@lothringen>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 15, 2022 at 04:52:26PM +0100, Frederic Weisbecker wrote:
> On Mon, Mar 14, 2022 at 03:35:04PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 14, 2022 at 01:26:10PM -0700, Paul E. McKenney wrote:
> > > On Mon, Mar 14, 2022 at 02:37:35PM +0100, Frederic Weisbecker wrote:
> > > > 
> > > > A few fixes especially for expedited GP polling causing a stall on TREE07,
> > > > as reported by Paul.
> > > > 
> > > > We may still want to optimize start_poll_synchronize_rcu_expedited() on
> > > > UP-no-preempt but I think Paul may be implying this while doing other
> > > > fixes.
> > > > 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > > 	rcu/dev
> > > > 
> > > > HEAD: 6e5fd7e614fd5c8f0fffeaa140b7ea697bfeb096
> > > > 
> > > > Thanks,
> > > > 	Frederic
> > > 
> > > I have pulled these in for review and testing, thank you!!!  I have
> > > started a ~90-minute test and will let you know how that goes.
> > 
> > And TREE05 doesn't like this much.  I get too-short grace periods.
> > TREE05 is unusual in being the one with the kernel build with
> > CONFIG_PREEMPT_NONE=y but also with CONFIG_PREEMPT_DYNAMIC=n.
> > 
> > Running tests of the commits individually.
> 
> Ouch, please test the following:
> 
> ---
> >From f180dd5809d2c3a6343cbd13f244b7b7f110a506 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker <frederic@kernel.org>
> Date: Tue, 15 Mar 2022 16:33:38 +0100
> Subject: [PATCH] rcutorture: Call preempt_schedule() through static call/key

You know, it would have been quite some time before I would have thought
to suspect that code, so thank you very much for chasing this down!

I have pulled it in, reverted my reversion of your patch 3/3, and started
a moderate set of tests.

							Thanx, Paul

> rcutorture sometimes want to trigger a random scheduler preemption call
> while simulating a read delay. However a direct call to
> preempt_schedule() is not desirable because it bypasses the static
> call/key filter used by CONFIG_PREEMPT_DYNAMIC. This breaks the
> no-preempt assumption in case the dynamic preemption mode is "none".
> 
> For example rcu_blocking_is_gp() is fooled and abbreviates grace periods
> when the CPU runs in no-preempt UP mode.
> 
> Fix this with making torture_preempt_schedule() to call through
> preempt dynamic static call/key.
> 
> Reported-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
>  include/linux/torture.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/torture.h b/include/linux/torture.h
> index 63fa4196e51c..7038104463e4 100644
> --- a/include/linux/torture.h
> +++ b/include/linux/torture.h
> @@ -118,7 +118,7 @@ void _torture_stop_kthread(char *m, struct task_struct **tp);
>  	_torture_stop_kthread("Stopping " #n " task", &(tp))
>  
>  #ifdef CONFIG_PREEMPTION
> -#define torture_preempt_schedule() preempt_schedule()
> +#define torture_preempt_schedule() __preempt_schedule()
>  #else
>  #define torture_preempt_schedule()	do { } while (0)
>  #endif
> -- 
> 2.25.1
> 

