From mboxrd@z Thu Jan 1 00:00:00 1970 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 0670FC54E94 for ; Thu, 26 Jan 2023 01:45:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229536AbjAZBpt (ORCPT ); Wed, 25 Jan 2023 20:45:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230208AbjAZBpq (ORCPT ); Wed, 25 Jan 2023 20:45:46 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 715A2611D2 for ; Wed, 25 Jan 2023 17:45:45 -0800 (PST) Received: (qmail 239293 invoked by uid 1000); 25 Jan 2023 20:45:44 -0500 Date: Wed, 25 Jan 2023 20:45:44 -0500 From: Alan Stern To: "Paul E. McKenney" Cc: Jonas Oberhauser , Andrea Parri , Jonas Oberhauser , Peter Zijlstra , 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: <20230125022019.GB2948950@paulmck-ThinkPad-P17-Gen-1> <20230125150520.GG2948950@paulmck-ThinkPad-P17-Gen-1> <20230125171832.GH2948950@paulmck-ThinkPad-P17-Gen-1> <20230125194651.GN2948950@paulmck-ThinkPad-P17-Gen-1> <20230125213832.GQ2948950@paulmck-ThinkPad-P17-Gen-1> <20230125233308.GA1552266@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230125233308.GA1552266@paulmck-ThinkPad-P17-Gen-1> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 25, 2023 at 03:33:08PM -0800, Paul E. McKenney wrote: > Ah, and returning to the earlier question as to whether srcu_read_unlock() > can use release semantics instead of smp_mb(), at the very least, this > portion of the synchronize_srcu() function's header comment must change: > > On systems with more than one CPU, when synchronize_srcu() > returns, each CPU is guaranteed to have executed a full > memory barrier since the end of its last corresponding SRCU > read-side critical section whose beginning preceded the call > to synchronize_srcu(). Yes, that would not be true. But on the other hand, it would be true that each CPU is guaranteed to have executed a release memory barrier since the end of its last corresponding SRCU read-side critical section whose beginning preceded the call to synchronize_srcu(), _and_ the CPU executing synchronize_srcu() is guaranteed to have executed a full memory barrier after seeing the values from all those release stores. This is not quite the same thing but it ought to be just as good. > I don't know of any SRCU code that relies on this, but it would be good to > check. There used to (and might still) be RCU code relying on this, which > is why this sentence was added to the header comment in the first place. If there is code relying on that guarantee, it ought to work just as well by relying on the modified guarantee. Of course, there might be code relying on a guarantee that srcu_read_unlock() executes a full memory barrier. This guarantee would certainly no longer hold. But as I understand it, this guarantee was never promised by the SRCU subsystem. Alan