From patchwork Wed Mar 15 19:38:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176602 Return-Path: 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 8BD97C61DA4 for ; Wed, 15 Mar 2023 19:39:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232864AbjCOTjZ (ORCPT ); Wed, 15 Mar 2023 15:39:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232258AbjCOTjN (ORCPT ); Wed, 15 Mar 2023 15:39:13 -0400 Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1256939CDC for ; Wed, 15 Mar 2023 12:39:12 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id o3so17397273qvr.1 for ; Wed, 15 Mar 2023 12:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909151; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=6kodpLrQnSozwTishADT/eFOoqfGUIFhFbZ2Rg+LiOA=; b=WByS267g9t6NJ1kyG9/EnjmxtgTNYbezAKGqyr8CaaBwqZINFEuA/ntWN6H+6kcZlm 0y0pivfDEqSC6+oWTYuc4+m0Ve4R+syrQBMCVHz35BK+o7Fx/qDMRs/tpQIZtjbMvVYM Z/STPa8OKdawLzzW22yLDCHQE1elXduZpbeGw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909151; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6kodpLrQnSozwTishADT/eFOoqfGUIFhFbZ2Rg+LiOA=; b=Ww2W9vjZMl8Swu+DLfre5ZZbPsmcI2OkXKU4P8eWFLvcuEEgIvtNuCUKGaMBBlNqUk elEXAZKYvZ/hfLQiuGiF0GBue1AFwmVBBkO7F51//+k1dJX2WB6qW7RK0m+xv/hXIs8y 5YrBPv0e1lTEdhNlZi6ctDrglh4KNBEUUXp29c7yYiqXncGOUJ6v9Ex8Ec/n3Ws4BnEi qzWP2w0RPGqQ38Pvdw9tRhWvwPMmDnK9b8+/aUJQE+9jK5MG35oa094h7ZbvO6mdWgPt omgAfGKJAAJSWt67mEfOZ4bjTJpRJak8zw8sus9H2gDboO2yL0eEZxyz0f/usSXvASau m7Og== X-Gm-Message-State: AO0yUKUvH0MIviyKIDWvjnLJuIALMKtn2E8tsVrRuL+A2RgxQbdv6y3C AcOBw8G7qkxcaEte4OZViTWzyCJYRMRblKLbKdo= X-Google-Smtp-Source: AK7set9xcFD5mrNuQbfScTwldN49ZVEM6uEf3ek4PJRMRU82tR8zA3YA+oKG8/u9a34gp1BqcGUv3g== X-Received: by 2002:a05:6214:20a7:b0:56e:fb4c:c1c4 with SMTP id 7-20020a05621420a700b0056efb4cc1c4mr32374960qvd.14.1678909151167; Wed, 15 Mar 2023 12:39:11 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:10 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, Lai Jiangshan , "Paul E. McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers Cc: Pingfan Liu , Frederic Weisbecker , "Zhang, Qiang1" , Joel Fernandes , rcu@vger.kernel.org Subject: [PATCH 1/6] srcu: Add comments for srcu_size_state Date: Wed, 15 Mar 2023 19:38:46 +0000 Message-Id: <20230315193851.8598-1-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org From: Pingfan Liu The SRCU_SIZE_* names are not self-explanatory, so this commit therefore adds comments to the definitions. Signed-off-by: Pingfan Liu Cc: Lai Jiangshan Cc: "Paul E. McKenney" Cc: Frederic Weisbecker Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: "Zhang, Qiang1" To: rcu@vger.kernel.org Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- include/linux/srcutree.h | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h index 558057b517b7..a6910805f9c5 100644 --- a/include/linux/srcutree.h +++ b/include/linux/srcutree.h @@ -92,16 +92,29 @@ struct srcu_struct { struct lockdep_map dep_map; }; -/* Values for size state variable (->srcu_size_state). */ -#define SRCU_SIZE_SMALL 0 -#define SRCU_SIZE_ALLOC 1 -#define SRCU_SIZE_WAIT_BARRIER 2 -#define SRCU_SIZE_WAIT_CALL 3 -#define SRCU_SIZE_WAIT_CBS1 4 -#define SRCU_SIZE_WAIT_CBS2 5 -#define SRCU_SIZE_WAIT_CBS3 6 -#define SRCU_SIZE_WAIT_CBS4 7 -#define SRCU_SIZE_BIG 8 +// Values for size state variable (->srcu_size_state). Once the state +// has been set to SRCU_SIZE_ALLOC, the grace-period code advances through +// this state machine one step per grace period until the SRCU_SIZE_BIG state +// is reached. Otherwise, the state machine remains in the SRCU_SIZE_SMALL +// state indefinitely. +#define SRCU_SIZE_SMALL 0 // No srcu_node combining tree, ->node == NULL +#define SRCU_SIZE_ALLOC 1 // An srcu_node tree is being allocated, initialized, + // and then referenced by ->node. It will not be used. +#define SRCU_SIZE_WAIT_BARRIER 2 // The srcu_node tree starts being used by everything + // except call_srcu(), especially by srcu_barrier(). + // By the end of this state, all CPUs and threads + // are aware of this tree's existence. +#define SRCU_SIZE_WAIT_CALL 3 // The srcu_node tree starts being used by call_srcu(). + // By the end of this state, all of the call_srcu() + // invocations that were running on a non-boot CPU + // and using the boot CPU's callback queue will have + // completed. +#define SRCU_SIZE_WAIT_CBS1 4 // Don't trust the ->srcu_have_cbs[] grace-period +#define SRCU_SIZE_WAIT_CBS2 5 // sequence elements or the ->srcu_data_have_cbs[] +#define SRCU_SIZE_WAIT_CBS3 6 // CPU-bitmask elements until all four elements of +#define SRCU_SIZE_WAIT_CBS4 7 // each array have been initialized. +#define SRCU_SIZE_BIG 8 // The srcu_node combining tree is fully initialized + // and all aspects of it are being put to use. /* Values for state variable (bottom bits of ->srcu_gp_seq). */ #define SRCU_STATE_IDLE 0 From patchwork Wed Mar 15 19:38:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176603 Return-Path: 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 80D12C7618A for ; Wed, 15 Mar 2023 19:39:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232921AbjCOTj0 (ORCPT ); Wed, 15 Mar 2023 15:39:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232285AbjCOTjO (ORCPT ); Wed, 15 Mar 2023 15:39:14 -0400 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FC614493 for ; Wed, 15 Mar 2023 12:39:13 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id y10so17515180qtj.2 for ; Wed, 15 Mar 2023 12:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909152; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=gkIW82Jn8PaGpB7B+YMqBxYys/Ya8U+pTY1r1WqXQ8E=; b=WDyMAh8LBvLv8TcPocJTlQ9oUFNWyhm52mv3Oy3aloVLjA3GPz2f/kf8L3QTmisA+e vZgmipdZ/oNQKbH4mBAG642qB5ciV2dFTAwbxCn78S00oXbU2BV2vHJUJJN4nLcJXPcT yt/KduCRJHeohmdt8cRIjsM2rwQYsvJ1QusRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909152; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gkIW82Jn8PaGpB7B+YMqBxYys/Ya8U+pTY1r1WqXQ8E=; b=aAlm0e8VTSTRogG1YTLfPPDXiDy4T7AtZ+rIJE3VxSn3T1LidIqpQlT5vHhpmJHKi3 Bl7XsgfQturFrPJxq2O4O2ykCOuzhgdZQRvQf2nh8TK+/wqmg7p0A+EbaG62TBorf6Y0 AGk/XmaP1GDjr8byCKKobfCbh87glBNWQuNxesPC7ocP06DVGuPDd4gjJSxsTq+xtCet ml2gmrprt7TMYEzGGZItbOQ0SbFYY6hwn+EyENliz7sEyvpcG9FDQEYPCib/OhbhSaJd H5sztgQlmSqbTTmjaA3A2yMZeS6MS6y2GG9dSYXiVxVapKJOGmmNnwCHGfqbFE+2XlYe dk4Q== X-Gm-Message-State: AO0yUKU80nU9rVKF7u9RBroKH/GufWp0CRcARUR95xKqiZqC8IV+84yO mXTy59+5VmoyxovnxgEvGPIwmg== X-Google-Smtp-Source: AK7set/lTZX4a5orBcEG4pZUqPqTc+JtcMojbfiFqsyvENbRhEu8ihMok00SZO1QIyKvQQxg2HMNhQ== X-Received: by 2002:a05:622a:284:b0:3bd:140c:91ed with SMTP id z4-20020a05622a028400b003bd140c91edmr1637192qtw.52.1678909152452; Wed, 15 Mar 2023 12:39:12 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:11 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Jonathan Corbet Cc: Qiuxu Zhuo , rcu@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH 2/6] Documentation/RCU: s/not/note/ in checklist.rst Date: Wed, 15 Mar 2023 19:38:47 +0000 Message-Id: <20230315193851.8598-2-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog In-Reply-To: <20230315193851.8598-1-joel@joelfernandes.org> References: <20230315193851.8598-1-joel@joelfernandes.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org From: Qiuxu Zhuo "Please not that you *cannot* rely..." has a typo. Fix it. Signed-off-by: Qiuxu Zhuo Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- Documentation/RCU/checklist.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index cc361fb01ed4..bd3c58c44bef 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -70,7 +70,7 @@ over a rather long period of time, but improvements are always welcome! can serve as rcu_read_lock_sched(), but is less readable and prevents lockdep from detecting locking issues. - Please not that you *cannot* rely on code known to be built + Please note that you *cannot* rely on code known to be built only in non-preemptible kernels. Such code can and will break, especially in kernels built with CONFIG_PREEMPT_COUNT=y. From patchwork Wed Mar 15 19:38:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176604 Return-Path: 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 8FDFCC7618D for ; Wed, 15 Mar 2023 19:39:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231716AbjCOTj1 (ORCPT ); Wed, 15 Mar 2023 15:39:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232500AbjCOTjQ (ORCPT ); Wed, 15 Mar 2023 15:39:16 -0400 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4C40279AE for ; Wed, 15 Mar 2023 12:39:14 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id cf14so17445500qtb.10 for ; Wed, 15 Mar 2023 12:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=toQXaUPvgeCcBAYiqMckeG88YIHFRuFoSXsrXPxs/ek=; b=aabRxvDGfMHTAOu1rCeWRfKFoj8/e+eofwzwu8sq5N2xxVoIbfEUCAmOtm4OtV0cEM 3LC2KDAp5IS7KK4K4qQLtxP+KXkQLpgZCw7uQ3zAxC4x1kEb19UNY5xIzVJMNoBQ+28S TFUhDoS/SN+A3vUukWz6JmpFnyeYUZO7AUhd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909153; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=toQXaUPvgeCcBAYiqMckeG88YIHFRuFoSXsrXPxs/ek=; b=poOUXYCMJ5GEXQVh4QQVZUYc+jrLkgcZ3shcuPwiz3JMz7pS6R+H0q6SOisbr+jcVz r+2aCIi+wJtz4tBWRXXKnUKfNCpZ9gxd8Vf3q7qsFC8LbztTZuTigE1WNyVw8HQdq8Hr DabbDxOlAsejV4EFSd/d91qqJEpE6YDf/Rrul7lbAkic0WUmj7/SNAxrwdSXNCUhmKx8 1+UoylVoVOWu70gDqInx6BNHV2QuewheZb3v4WJd+tLSKUPuvjafb9k0bXRH0rdsjjGe kTEu0BPJvTy9NC2867rdCPD5M8NPqkNKRbDzThw9IzDq0fD/nUkl3qHNLV0165VepdkW 0YqA== X-Gm-Message-State: AO0yUKUIlJWHdywAlbmtAiRprE1cwLaROXSm9UF3sc6LERjhsbHc1SEe UankNQw1mWm+4LyejNz2dW+Xcw== X-Google-Smtp-Source: AK7set+O2OmB6N6d0SpCuwIUEUsFxeLjjnIp7nmGbwF1he2wDDp+9RyhFBCbjYaZ8NBaYgMgM66zVA== X-Received: by 2002:a05:622a:1d5:b0:3b9:b761:b0a0 with SMTP id t21-20020a05622a01d500b003b9b761b0a0mr2005215qtw.12.1678909153579; Wed, 15 Mar 2023 12:39:13 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:13 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, Lai Jiangshan , "Paul E. McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers Cc: "Joel Fernandes (Google)" , Frederic Weisbecker , Boqun Feng , rcu@vger.kernel.org Subject: [PATCH 3/6] srcu: Clarify comments on memory barrier "E" Date: Wed, 15 Mar 2023 19:38:48 +0000 Message-Id: <20230315193851.8598-3-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog In-Reply-To: <20230315193851.8598-1-joel@joelfernandes.org> References: <20230315193851.8598-1-joel@joelfernandes.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org There is an smp_mb() named "E" in srcu_flip() immediately before the increment (flip) of the srcu_struct structure's ->srcu_idx. The purpose of E is to order the preceding scan's read of lock counters against the flipping of the ->srcu_idx, in order to prevent new readers from continuing to use the old ->srcu_idx value, which might needlessly extend the grace period. However, this ordering is already enforced because of the control dependency between the preceding scan and the ->srcu_idx flip. This control dependency exists because atomic_long_read() is used to scan the counts, because WRITE_ONCE() is used to flip ->srcu_idx, and because ->srcu_idx is not flipped until the ->srcu_lock_count[] and ->srcu_unlock_count[] counts match. And such a match cannot happen when there is an in-flight reader that started before the flip (observation courtesy Mathieu Desnoyers). The litmus test below (courtesy of Frederic Weisbecker, with changes for ctrldep by Boqun and Joel) shows this: C srcu (* * bad condition: P0's first scan (SCAN1) saw P1's idx=0 LOCK count inc, though P1 saw flip. * * So basically, the ->po ordering on both P0 and P1 is enforced via ->ppo * (control deps) on both sides, and both P0 and P1 are interconnected by ->rf * relations. Combining the ->ppo with ->rf, a cycle is impossible. *) {} // updater P0(int *IDX, int *LOCK0, int *UNLOCK0, int *LOCK1, int *UNLOCK1) { int lock1; int unlock1; int lock0; int unlock0; // SCAN1 unlock1 = READ_ONCE(*UNLOCK1); smp_mb(); // A lock1 = READ_ONCE(*LOCK1); // FLIP if (lock1 == unlock1) { // Control dep smp_mb(); // E // Remove E and still passes. WRITE_ONCE(*IDX, 1); smp_mb(); // D // SCAN2 unlock0 = READ_ONCE(*UNLOCK0); smp_mb(); // A lock0 = READ_ONCE(*LOCK0); } } // reader P1(int *IDX, int *LOCK0, int *UNLOCK0, int *LOCK1, int *UNLOCK1) { int tmp; int idx1; int idx2; // 1st reader idx1 = READ_ONCE(*IDX); if (idx1 == 0) { // Control dep tmp = READ_ONCE(*LOCK0); WRITE_ONCE(*LOCK0, tmp + 1); smp_mb(); /* B and C */ tmp = READ_ONCE(*UNLOCK0); WRITE_ONCE(*UNLOCK0, tmp + 1); } else { tmp = READ_ONCE(*LOCK1); WRITE_ONCE(*LOCK1, tmp + 1); smp_mb(); /* B and C */ tmp = READ_ONCE(*UNLOCK1); WRITE_ONCE(*UNLOCK1, tmp + 1); } } exists (0:lock1=1 /\ 1:idx1=1) More complicated litmus tests with multiple SRCU readers also show that memory barrier E is not needed. This commit therefore clarifies the comment on memory barrier E. Why not also remove that redundant smp_mb()? Because control dependencies are quite fragile due to their not being recognized by most compilers and tools. Control dependencies therefore exact an ongoing maintenance burden, and such a burden cannot be justified in this slowpath. Therefore, that smp_mb() stays until such time as its overhead becomes a measurable problem in a real workload running on a real production system, or until such time as compilers start paying attention to this sort of control dependency. Co-developed-by: Frederic Weisbecker Signed-off-by: Frederic Weisbecker Co-developed-by: Mathieu Desnoyers Signed-off-by: Mathieu Desnoyers Co-developed-by: Boqun Feng Signed-off-by: Boqun Feng Reviewed-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/srcutree.c | 34 +++++++++++++++++++++++++++------- 1 file changed, 27 insertions(+), 7 deletions(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index ab4ee58af84b..68f89c533057 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -1085,16 +1085,36 @@ static bool try_check_zero(struct srcu_struct *ssp, int idx, int trycount) static void srcu_flip(struct srcu_struct *ssp) { /* - * Ensure that if this updater saw a given reader's increment - * from __srcu_read_lock(), that reader was using an old value - * of ->srcu_idx. Also ensure that if a given reader sees the - * new value of ->srcu_idx, this updater's earlier scans cannot - * have seen that reader's increments (which is OK, because this - * grace period need not wait on that reader). + * Because the flip of ->srcu_idx is executed only if the + * preceding call to srcu_readers_active_idx_check() found that + * the ->srcu_unlock_count[] and ->srcu_lock_count[] sums matched + * and because that summing uses atomic_long_read(), there is + * ordering due to a control dependency between that summing and + * the WRITE_ONCE() in this call to srcu_flip(). This ordering + * ensures that if this updater saw a given reader's increment from + * __srcu_read_lock(), that reader was using a value of ->srcu_idx + * from before the previous call to srcu_flip(), which should be + * quite rare. This ordering thus helps forward progress because + * the grace period could otherwise be delayed by additional + * calls to __srcu_read_lock() using that old (soon to be new) + * value of ->srcu_idx. + * + * This sum-equality check and ordering also ensures that if + * a given call to __srcu_read_lock() uses the new value of + * ->srcu_idx, this updater's earlier scans cannot have seen + * that reader's increments, which is all to the good, because + * this grace period need not wait on that reader. After all, + * if those earlier scans had seen that reader, there would have + * been a sum mismatch and this code would not be reached. + * + * This means that the following smp_mb() is redundant, but + * it stays until either (1) Compilers learn about this sort of + * control dependency or (2) Some production workload running on + * a production system is unduly delayed by this slowpath smp_mb(). */ smp_mb(); /* E */ /* Pairs with B and C. */ - WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1); + WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1); // Flip the counter. /* * Ensure that if the updater misses an __srcu_read_unlock() From patchwork Wed Mar 15 19:38:49 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176605 Return-Path: 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 50289C7618A for ; Wed, 15 Mar 2023 19:39:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232308AbjCOTj3 (ORCPT ); Wed, 15 Mar 2023 15:39:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232630AbjCOTjY (ORCPT ); Wed, 15 Mar 2023 15:39:24 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B32060D65 for ; Wed, 15 Mar 2023 12:39:16 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id qh28so1139851qvb.7 for ; Wed, 15 Mar 2023 12:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909155; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FZQhYsvSmWyuhycEwUPUuLVCJi5L/larxVRjodrPgYU=; b=WPzp7vzhgULJB2A4jk1YcDWNT1jobRT1Ako/o+cRiCARG56+shVqIoIt4PgSos4evO FIJjUyWumnqa5ztJqHnm/Bl0SN05mH5YBYPmo5nO/7nl+Dg4qzpD8ZJdUeQmDXg3a3l+ 07fArh0ALdM0jYUmpKU1a4ZPhZK8IyVKtz3LQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909155; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FZQhYsvSmWyuhycEwUPUuLVCJi5L/larxVRjodrPgYU=; b=O/p2/mYgDO3txGKTYgcjTWjpjWeUikuT6oNRS0HptsFW7tBK0s5vVsrcy/l5zJZR2A QyffHO0Wh0eXkQEAOYrWrNi5h7oQHp+E32Z6lsges5q7v2pWFHZv3tjPBAdISU63a4T1 pdAWzP3RjrzA0Bbx4LR+PcHfATRBrJ1EeCCBPWvMqzO5ffAefMisTtnOdkB4W/b8VXpe 9N5DSa8hVn1iRC1tLc35TxBldhFmwFIdx5AxDlPK202F3SnGjxy/Mp70KUoA6/T99u22 L37a8rSxXdaFwVP4WJvInap0nIRGn9FF5QojmYHCsH4JBBDb7NYK27+8GQfSiEOeCcTH 1q0g== X-Gm-Message-State: AO0yUKWXVDt9oGxj2PwgQvog28iKBbzv0vMqhtvbd8tG7MmH0/wJ2BZa nv3dXGAN+4jBZEm+P6PUfHOJlg== X-Google-Smtp-Source: AK7set/BS4KvAf22SZ3pUETcpzcy8qj4TfbnI/y1P1fLDLmHD7qK7T2GWim/udjQaYTGfP+pydeECw== X-Received: by 2002:a05:6214:1d0b:b0:5ab:f46:e094 with SMTP id e11-20020a0562141d0b00b005ab0f46e094mr16549743qvd.49.1678909155498; Wed, 15 Mar 2023 12:39:15 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:15 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Jonathan Corbet , Davidlohr Bueso Cc: Randy Dunlap , linux-doc@vger.kernel.org, rcu@vger.kernel.org Subject: [PATCH 4/6] Documentation: RCU: Correct spelling Date: Wed, 15 Mar 2023 19:38:49 +0000 Message-Id: <20230315193851.8598-4-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog In-Reply-To: <20230315193851.8598-1-joel@joelfernandes.org> References: <20230315193851.8598-1-joel@joelfernandes.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org From: Randy Dunlap Correct spelling problems for Documentation/RCU/ as reported by codespell. Note: in RTFP.txt, there are other misspellings that are left as is since they were used that way in email Subject: lines or in LWN.net articles. [preemptable, Preemptable, synchonisation] Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Cc: "Paul E. McKenney" Cc: Frederic Weisbecker Cc: Neeraj Upadhyay Cc: Josh Triplett Cc: rcu@vger.kernel.org Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- .../Expedited-Grace-Periods.rst | 6 +++--- .../Memory-Ordering/Tree-RCU-Memory-Ordering.rst | 2 +- Documentation/RCU/RTFP.txt | 10 +++++----- Documentation/RCU/UP.rst | 4 ++-- Documentation/RCU/lockdep.rst | 2 +- Documentation/RCU/torture.rst | 4 ++-- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst index c9c957c85bac..93d899d53258 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst @@ -277,7 +277,7 @@ the following access functions: Again, only one request in a given batch need actually carry out a grace-period operation, which means there must be an efficient way to -identify which of many concurrent reqeusts will initiate the grace +identify which of many concurrent requests will initiate the grace period, and that there be an efficient way for the remaining requests to wait for that grace period to complete. However, that is the topic of the next section. @@ -405,7 +405,7 @@ Use of Workqueues In earlier implementations, the task requesting the expedited grace period also drove it to completion. This straightforward approach had the disadvantage of needing to account for POSIX signals sent to user -tasks, so more recent implemementations use the Linux kernel's +tasks, so more recent implementations use the Linux kernel's workqueues (see Documentation/core-api/workqueue.rst). The requesting task still does counter snapshotting and funnel-lock @@ -465,7 +465,7 @@ corresponding disadvantage that workqueues cannot be used until they are initialized, which does not happen until some time after the scheduler spawns the first task. Given that there are parts of the kernel that really do want to execute grace periods during this mid-boot “dead -zone”, expedited grace periods must do something else during thie time. +zone”, expedited grace periods must do something else during this time. What they do is to fall back to the old practice of requiring that the requesting task drive the expedited grace period, as was the case before diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 7fdf151a8680..5750f125361b 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to detect idle CPUs. +-----------------------------------------------------------------------+ The approach must be extended to handle one final case, that of waking a -task blocked in ``synchronize_rcu()``. This task might be affinitied to +task blocked in ``synchronize_rcu()``. This task might be affined to a CPU that is not yet aware that the grace period has ended, and thus might not yet be subject to the grace period's memory ordering. Therefore, there is an ``smp_mb()`` after the return from diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 588d97366a46..db8f16b392aa 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425]. In 2012, Josh Triplett received his Ph.D. with his dissertation covering RCU-protected resizable hash tables and the relationship between memory barriers and read-side traversal order: If the updater -is making changes in the opposite direction from the read-side traveral +is making changes in the opposite direction from the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates [JoshTriplettPhD]. Also in 2012, @@ -1245,7 +1245,7 @@ Oregon Health and Sciences University" [Viewed September 5, 2005]" ,annotation={ First posting showing how RCU can be safely adapted for - preemptable RCU read side critical sections. + preemptible RCU read side critical sections. } } @@ -1888,7 +1888,7 @@ Revised: \url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com} [Viewed October 25, 2007]" ,annotation={ - Final patch for preemptable RCU to -rt. (Later patches were + Final patch for preemptible RCU to -rt. (Later patches were to mainline, eventually incorporated.) } } @@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!" \url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com} [Viewed August 15, 2009]" ,annotation={ - First posting of simple and fast preemptable RCU. + First posting of simple and fast preemptible RCU. } } @@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!" RCU-protected hash tables, barriers vs. read-side traversal order. . If the updater is making changes in the opposite direction from - the read-side traveral order, the updater need only execute a + the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates. diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst index 8b20fd45f255..4060d7a2f62a 100644 --- a/Documentation/RCU/UP.rst +++ b/Documentation/RCU/UP.rst @@ -107,7 +107,7 @@ UP systems, including PREEMPT SMP builds running on UP systems. Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems running - preemptable RCU? + preemptible RCU? .. _answer_quick_quiz_up: @@ -143,7 +143,7 @@ Answer to Quick Quiz #2: Answer to Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems - running preemptable RCU? + running preemptible RCU? Because some other task might have been preempted in the middle of an RCU read-side critical section. If synchronize_rcu() diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst index 2749f43ec1b0..69e73a39bd11 100644 --- a/Documentation/RCU/lockdep.rst +++ b/Documentation/RCU/lockdep.rst @@ -65,7 +65,7 @@ checking of rcu_dereference() primitives: rcu_access_pointer(p): Return the value of the pointer and omit all barriers, but retain the compiler constraints that prevent duplicating - or coalescsing. This is useful when testing the + or coalescing. This is useful when testing the value of the pointer itself, for example, against NULL. The rcu_dereference_check() check expression can be any boolean diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst index 0316ba0c6922..b3b6dfa85248 100644 --- a/Documentation/RCU/torture.rst +++ b/Documentation/RCU/torture.rst @@ -216,7 +216,7 @@ Kernel boot arguments can also be supplied, for example, to control rcutorture's module parameters. For example, to test a change to RCU's CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'". This will of course result in the scripting reporting a failure, namely -the resuling RCU CPU stall warning. As noted above, reducing memory may +the resulting RCU CPU stall warning. As noted above, reducing memory may require disabling rcutorture's callback-flooding tests:: kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ @@ -370,5 +370,5 @@ You can also re-run a previous remote run in a manner similar to kvm.sh: tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \ --duration 24h -In this case, most of the kvm-again.sh parmeters may be supplied following +In this case, most of the kvm-again.sh parameters may be supplied following the pathname of the old run-results directory. From patchwork Wed Mar 15 19:38:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176606 Return-Path: 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 24B65C76195 for ; Wed, 15 Mar 2023 19:39:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232603AbjCOTja (ORCPT ); Wed, 15 Mar 2023 15:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232850AbjCOTjZ (ORCPT ); Wed, 15 Mar 2023 15:39:25 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 891D562862 for ; Wed, 15 Mar 2023 12:39:17 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id x8so2282079qvr.9 for ; Wed, 15 Mar 2023 12:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909156; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=axV3b7MOxr7kX8qyghaLBRtLrKYOLo8UOyKWzHAv10o=; b=dr2eaYvkOgPd0aEVBn12iOIdTI+nYzWGoFDs+yIe7nf4LdBfmjyuUqyx6BARTlwxjL NjDOPUlwUYo5ofycWAMbOEXXiQYNiANpL8ohKlu1F2bwYXyd7rtEx2eMzpUz4iDhO306 OarLgjafO56s3QGKCDqYYd+/feEM7oaN7Ti+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909156; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=axV3b7MOxr7kX8qyghaLBRtLrKYOLo8UOyKWzHAv10o=; b=So/KOXUfdnu1KLRaS4yX7UNh4aTcKaLgbrKi2d8Ybp7/ZB4QleiVEctrayqJZy4Nc9 kehp7GdkYiD7iYkBLYwUH+Y+B1g9GLstc1HEwCj482yzS3aW4eOy7hjetVU7m/nsCWne ZSVOkRpd/E/5zbs3nCIfqexb64bkOnYLWmZJUsOEEwP78nZ+0CpJnPj7aN+27cTEcthQ xC1ErAdeyzhcaxwe17eeyPoqFeCHNr9JUNbe+T9kaA3HLMViihMJMRaN3nmiwGLMgq+G RmsForgBZ5eTlxMmtbSXKGTw5aNSNJAwGqnK8FdjQBbF8LawgLfz4du1UEnQCepHmQps bsYQ== X-Gm-Message-State: AO0yUKUxfMer7eQL9UiUaf2Q4TpZzi9vK+F3AouWg0Kw0UmofqEd4z0R hgjjSaE5PETXJqfUGwveIHv+tQ== X-Google-Smtp-Source: AK7set+jtVfX9Tlj3CkDKphbC220Zm791x7Gq+bhmf4ftIqzp6M4xdC/sqOnxIO46wsS32cUnIjong== X-Received: by 2002:a05:6214:23c9:b0:56f:c138:2844 with SMTP id hr9-20020a05621423c900b0056fc1382844mr26775671qvb.37.1678909156672; Wed, 15 Mar 2023 12:39:16 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:16 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Jonathan Corbet Cc: "Uladzislau Rezki (Sony)" , rcu@vger.kernel.org, linux-doc@vger.kernel.org Subject: [PATCH 5/6] doc: Update whatisRCU.rst Date: Wed, 15 Mar 2023 19:38:50 +0000 Message-Id: <20230315193851.8598-5-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog In-Reply-To: <20230315193851.8598-1-joel@joelfernandes.org> References: <20230315193851.8598-1-joel@joelfernandes.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org From: "Uladzislau Rezki (Sony)" The kfree_rcu() macro is deprecated. Rename it to its new kfree_rcu_mightsleep() name in this documentation. Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- Documentation/RCU/whatisRCU.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 2c5563a91998..8eddef28d3a1 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -597,10 +597,10 @@ to avoid having to write your own callback:: If the occasional sleep is permitted, the single-argument form may be used, omitting the rcu_head structure from struct foo. - kfree_rcu(old_fp); + kfree_rcu_mightsleep(old_fp); -This variant of kfree_rcu() almost never blocks, but might do so by -invoking synchronize_rcu() in response to memory-allocation failure. +This variant almost never blocks, but might do so by invoking +synchronize_rcu() in response to memory-allocation failure. Again, see checklist.rst for additional rules governing the use of RCU. From patchwork Wed Mar 15 19:38:51 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 13176607 Return-Path: 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 410EBC61DA4 for ; Wed, 15 Mar 2023 19:39:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232714AbjCOTja (ORCPT ); Wed, 15 Mar 2023 15:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232893AbjCOTj0 (ORCPT ); Wed, 15 Mar 2023 15:39:26 -0400 Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A28506700A for ; Wed, 15 Mar 2023 12:39:18 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id l13so17508836qtv.3 for ; Wed, 15 Mar 2023 12:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1678909158; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=H58NOkpBsborYqDlb6apVPOFULtTVVJdIxtX+vdpwc4=; b=C093a986XM+BY5phSly7wrGZCcmMxTiTlUfXZxpE7QnM3ZVj5e2y6nnNsgpnj1q4g3 b6kqPR4fnmeuu41UvzmMuQxZPdQQZyQ53vE4qe5XrF40jJi2gYTkZ1sgrCn/kXrFPMt0 uDqqMdAuP1MgwDf5FFqNt6sQOBCop356zuIeo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678909158; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H58NOkpBsborYqDlb6apVPOFULtTVVJdIxtX+vdpwc4=; b=OHIvdCMxJPZUv5+QdApRTe9/YOonu+94A4u6r7BlO28xGzKNPoJJxNgxqhZTP33uv3 Ml4dk5GdV6vdb21GFjvec/p7tFtlFPhneg6VlpBOrB+689kopkWOVIVhuBUJWdbKK3aW vJyJfGjeKnUGjS37voQgD8UBJeBwHxWUgUkoOctTWEJj+lhI4XeVMGgiADVmSVOupcjW 5953w5iau48AotAP/7ph817tpdyQ1wbyrxn/IKoXXR9Ktt3cOK2kVLo8TGf31Nya95YA fKak7Jd75GpkPsR/01exQbsLkkRLUUpLzy9R//vwbLNDgaItSHiL7+8lxtH+nAJ2ckfE ijNg== X-Gm-Message-State: AO0yUKV4De1ZANfLtO/PdLaf4fid/7m330D14rnsqJ7ZWY93j6aKvrcu 9NfpmX3dnVZcEoGxOy/3YlSycA== X-Google-Smtp-Source: AK7set/66oK6XSfs52GYzh6EZaoShJeuEtQsucB4O83OGbah83EM8uB0VUPPO6XgJzFDF7lhYm8bvQ== X-Received: by 2002:ac8:5bca:0:b0:3bf:be4b:808c with SMTP id b10-20020ac85bca000000b003bfbe4b808cmr1465528qtb.55.1678909157780; Wed, 15 Mar 2023 12:39:17 -0700 (PDT) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a254a00b00745af48838bsm4347227qko.5.2023.03.15.12.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 12:39:17 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes Cc: rcu@vger.kernel.org Subject: [PATCH 6/6] rcu: Add comment to rcu_do_batch() identifying rcuoc code path Date: Wed, 15 Mar 2023 19:38:51 +0000 Message-Id: <20230315193851.8598-6-joel@joelfernandes.org> X-Mailer: git-send-email 2.40.0.rc1.284.g88254d51c5-goog In-Reply-To: <20230315193851.8598-1-joel@joelfernandes.org> References: <20230315193851.8598-1-joel@joelfernandes.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org From: "Paul E. McKenney" This commit adds a comment to help explain why the "else" clause of the in_serving_softirq() "if" statement does not need to enforce a time limit. The reason is that this "else" clause handles rcuoc kthreads that do not block handlers for other softirq vectors. Signed-off-by: Paul E. McKenney Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/tree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 8e880c09ab59..06cc6a6ad819 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2131,6 +2131,8 @@ static void rcu_do_batch(struct rcu_data *rdp) break; } } else { + // In rcuoc context, so no worries about depriving + // other softirq vectors of CPU cycles. local_bh_enable(); lockdep_assert_irqs_enabled(); cond_resched_tasks_rcu_qs();