Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1187091rwb; Fri, 13 Jan 2023 08:59:43 -0800 (PST) X-Google-Smtp-Source: AMrXdXvYvRMIgc4wvuS68Dj10+1+XmjYqp9CM0bfNeWRlI0hyN+FT4CMsEYTVxdXW3Yz1CVvgTnA X-Received: by 2002:a17:902:a513:b0:189:c94c:6906 with SMTP id s19-20020a170902a51300b00189c94c6906mr64551267plq.60.1673629182775; Fri, 13 Jan 2023 08:59:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673629182; cv=none; d=google.com; s=arc-20160816; b=YirgjDGPRaoCkdNo1t/b+o2eoPtbyCyR8w99Rwtw2JGZrlyqWirTQU63prC5HaXdha JaPMA//BMR+kngg0Yoc3k8FrzDyynXQsAxIqS5IOboEYGXh7BzD0NdrvljMkcIKmYuLH DpwR5OCQxVS8F06HzUaarIesoFDRt1yfhpfSPsG8Ctf/YcYdALbTFA/9kRKk+ZKsU3Nm vrzfEmLpz5aQMjtlodsiIn4vx/GG5Sm99yQeuJmqYhgB7dEztP0nMBATEB9Px6i4n07o WBnsFz67qfPJsY0MCDzwAT/Hbjmvw89J3QGj407d5ah5tQ2intijc/PZGoe3+M44zF+7 hMDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=qIcayW5swo86jOSJtEL7Vz3D148Nh1bI9fkTtbCp4AY=; b=ivubt+gVTcUHFKEDXOL2dOX8vbFSHi60QttIroAL0TpWyFBCmQengZz2U2sf5V6upP JUJ4iTzPub6Js+ESBVjG61FweTLUnDY5g+8uFs9sH2DUc1u57NbTAqB9lij0IzVgYcrc ru6o5VHNGNdGUv0c4xwWfb7solWigJAHMhw2aqvYwxL4qJU+NRJW4R2X5DnD2P4WYUih 1F3lL2wUHd7XGvDyn7R+n8/C/6mCcP6s0DvZ5eaa+sTennUVek1+OqHWdhaJQytzjA3I cRFmDM6TgCd5sQll4FcCijkyRKyl7mvR+CH0JEzEIOCO1jbPubitjKEiUSdaR3RFUWuE DL3A== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z6-20020a170902ccc600b001898141f0edsi21889810ple.159.2023.01.13.08.59.36; Fri, 13 Jan 2023 08:59:42 -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; 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 S229697AbjAMQkx (ORCPT + 51 others); Fri, 13 Jan 2023 11:40:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230249AbjAMQka (ORCPT ); Fri, 13 Jan 2023 11:40:30 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id E1213D2F3 for ; Fri, 13 Jan 2023 08:38:17 -0800 (PST) Received: (qmail 25781 invoked by uid 1000); 13 Jan 2023 11:38:17 -0500 Date: Fri, 13 Jan 2023 11:38:17 -0500 From: Alan Stern To: "Paul E. McKenney" Cc: Jonas Oberhauser , Peter Zijlstra , "parri.andrea" , will , "boqun.feng" , npiggin , dhowells , "j.alglave" , "luc.maranget" , akiyks , dlustig , joel , urezki , quic_neeraju , frederic , Kernel development list Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test) Message-ID: References: <20220921173109.GA1214281@paulmck-ThinkPad-P17-Gen-1> <114ECED5-FED1-4361-94F7-8D9BC02449B7> <07579baee4b84532a76ea8b0b33052bb@huawei.com> <20230112215716.GS4028633@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230112215716.GS4028633@paulmck-ThinkPad-P17-Gen-1> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS autolearn=no 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 On Thu, Jan 12, 2023 at 01:57:16PM -0800, Paul E. McKenney wrote: > I will risk sharing the intuition behind the rcu-order counting rule. > > In the code, an RCU read-side critical section begins with rcu_read_lock() > and ends with the matching rcu_read_unlock(). RCU read-side critical > section may be nested, in which case RCU cares only about the outermost > of the nested set. > > An RCU grace period includes at least one moment in time during which > each and every process/CPU/task/whatever is not within an RCU read-side > critical section. Strictly speaking, this is not right. It should say: For each process/CPU/task/whatever, an RCU grace period includes at least one moment in time during which that process is not within an RCU read-side critical section. There does not have to be any single moment during which no processes are executing a critical section. For example, the following is acceptable: CPU 0: start of synchronize_rcu()......end CPU 1: rcu_lock().....................rcu_unlock() CPU 2: rcu_lock().......................rcu_unlock() Alan