From patchwork Tue Jan 3 17:56:54 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Fernandes X-Patchwork-Id: 38568 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp4746210wrt; Tue, 3 Jan 2023 10:01:13 -0800 (PST) X-Google-Smtp-Source: AMrXdXvjvbyH/Wp0oQajEGQrPNO4+vSyJQ/xnGkB31O3QRyMBd4JLmc7ccmRzC/Un2hli9Hxk8jI X-Received: by 2002:a05:6402:c44:b0:48e:ac4e:7bfa with SMTP id cs4-20020a0564020c4400b0048eac4e7bfamr4763216edb.2.1672768873812; Tue, 03 Jan 2023 10:01:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672768873; cv=none; d=google.com; s=arc-20160816; b=SXXJzJUZbcVJC3COvH79xHNn9bJ3wpTHf3X6Y62NSAGt+zf2Sw/rJ+OepzvINBBk6a FSFJGVUGiJIkI80RY10mBBjWZvE5XfjGrdtT6JAzEB8YroMSGS9NRie1xKdomcoeW7Cq QHL5w/Xlw0TW9ne04WOm+iqRjxBc1f0woRfZiXZiAp61S6b54p6F7iHVBvm3IN5lrjVh /FMYcDU0D1mDoqv/n0NZQEREX+gWjhzsPrqb/Y/zinN7sb/vl36n2aqw5IXi3IUhE+Kf SFW3poGsVGuohlY5p4ACopVp+5hU3QH76AOwR3m+GrFEeTPlSLneK4vjqFtADBrRw+U7 DFGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ixGyFkrV0xqrkiJ3p7VqvfkszCi48OTsH11wl3xFQLU=; b=0aQ/VMRGYrbfSUBncSad/U6cKvhqIkh6BsTodVqMXwpVtifjTWFx7SzBauiJafI7xC RvXIPwqKSX78Z335i+vW3u6mqLbiFDCl9A47IMpKoogoKT05pQkqloCbtkLWSo33dbnw ZS6+f/G1dNqforK16wjvtXpigGs5oo517pPb1IjaRR10FRp5Aaxdx3cXRmG5Ij2H9NPV Vb3QcnjX3nZc3MU7cICRd0W3sXLrhl5krON3TBLc4USvkHHFn6iZGYGIcT73KWjQlXr/ jGBx4iRaIsMG/9TpVT6Sf8T/UNhLviOPbpZT4SfnRS8n7oQLIJ8FYdAoOOu81rBfBu0e CIjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=sRUosVhs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i14-20020a05640242ce00b0047531b0169asi32013799edc.301.2023.01.03.10.00.48; Tue, 03 Jan 2023 10:01:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=sRUosVhs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238286AbjACR5e (ORCPT + 99 others); Tue, 3 Jan 2023 12:57:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238285AbjACR5L (ORCPT ); Tue, 3 Jan 2023 12:57:11 -0500 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36C451057B for ; Tue, 3 Jan 2023 09:57:08 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id c7so25111418qtw.8 for ; Tue, 03 Jan 2023 09:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ixGyFkrV0xqrkiJ3p7VqvfkszCi48OTsH11wl3xFQLU=; b=sRUosVhssD0en5joF9vLLUpX8V0Mn5UlDYOilUJ2tyvRYgMexyinwnRJCc3npDcj9I geM1NnHZAfGfSpvgKWqCzimVnD6QWlnqEenqostnemsBY4KDrX8lFXhtceyrzwT9moVs Jc1VYidMjKKFAdRJEyu7HFp5pWDwhhcubFJ1g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ixGyFkrV0xqrkiJ3p7VqvfkszCi48OTsH11wl3xFQLU=; b=3c1wBVbCqNMvejTbzAfEkCyfAq60HqMju4xnOh4RhLJf45dKzS0tiQwsUBmWaGZHi1 /JTbc8XlSOKbb3XTTYBl7bmPJ7k0zb0owcYORNSh6YNFOtrQR+RuEMiMLy4vS3LoafPy ZG+eUDNw/X+FNzDJDBtzafcIzQKsmFcg09zcB7+8RmWsGHZSiJFWvWcbkqfgK9QBV4bI 3i/AmfATm/XxLgu36wDSvOKrnk3Zkp7oRN+sN53Uh0ZDaCt015M1GQ6Re1bdeLW2Ys3y bTXnw+tBdOF7VPYPu7fBvYJ1CR3UzuOTh5yvkxh97I7mkWHSts/lZXUQhHYRcC5hQ0rC J63Q== X-Gm-Message-State: AFqh2koOaTLKGzZU4HMowhHfKH2K6gj40OI/Xj0E0I6byAD2hhG78PBN KKNVPaRPce2lTrvyrBisFMBpt7EMHgUYKTJR X-Received: by 2002:ac8:4602:0:b0:3ab:6312:f306 with SMTP id p2-20020ac84602000000b003ab6312f306mr64154599qtn.4.1672768626223; Tue, 03 Jan 2023 09:57:06 -0800 (PST) Received: from joelboxx.c.googlers.com.com (228.221.150.34.bc.googleusercontent.com. [34.150.221.228]) by smtp.gmail.com with ESMTPSA id d21-20020ac86695000000b0038b684a1642sm19136842qtp.32.2023.01.03.09.57.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jan 2023 09:57:05 -0800 (PST) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Frederic Weisbecker , Mathieu Desnoyers , Boqun Feng , Josh Triplett , Lai Jiangshan , "Paul E. McKenney" , rcu@vger.kernel.org, Steven Rostedt , neeraj.iitr10@gmail.com Subject: [PATCH v3] srcu: Remove memory barrier "E" as it does not do anything Date: Tue, 3 Jan 2023 17:56:54 +0000 Message-Id: <20230103175654.1913192-1-joel@joelfernandes.org> X-Mailer: git-send-email 2.39.0.314.g84b9a713c41-goog MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754025216351914748?= X-GMAIL-MSGID: =?utf-8?q?1754025294749130660?= During a flip, we have a full memory barrier before srcu_idx is incremented. The idea is we intend to order the first phase scan's read of lock counters with the flipping of the index. However, such ordering is already enforced because of the control-dependency between the 2 scans. We would be flipping the index only if lock and unlock counts matched. But such match will not happen if there was a pending reader before the flip in the first place (observation courtesy Mathieu Desnoyers). The litmus test below shows this: (test courtesy Frederic Weisbecker, Changes for ctrldep by Boqun/me): 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) This commit therefore removes memory barrier E, as memory barriers are not free, and clarifies the old comment. Co-developed-by: Frederic Weisbecker Co-developed-by: Mathieu Desnoyers Co-developed-by: Boqun Feng Signed-off-by: Joel Fernandes (Google) --- v1->v2: Update changelog, keep old comments. v2->v3: Moar changelog updates. kernel/rcu/srcutree.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index 1c304fec89c0..0f9ba0f9fd12 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -983,15 +983,15 @@ 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). + * Control dependencies on both reader and updater side ensures 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 ensures 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). + * + * So no need for an smp_mb() before incrementing srcu_idx. */ - smp_mb(); /* E */ /* Pairs with B and C. */ - WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1); /*