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 5EC68C05027 for ; Mon, 23 Jan 2023 20:34:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232526AbjAWUeE (ORCPT ); Mon, 23 Jan 2023 15:34:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229791AbjAWUeD (ORCPT ); Mon, 23 Jan 2023 15:34:03 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 50D767EF2 for ; Mon, 23 Jan 2023 12:34:01 -0800 (PST) Received: (qmail 140088 invoked by uid 1000); 23 Jan 2023 15:34:00 -0500 Date: Mon, 23 Jan 2023 15:34:00 -0500 From: Alan Stern To: Jonas Oberhauser Cc: paulmck@kernel.org, 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: <20230119001147.GN2948950@paulmck-ThinkPad-P17-Gen-1> <0fae983b-2a7c-d44e-8881-53d5cc053f09@huaweicloud.com> <20230119184107.GT2948950@paulmck-ThinkPad-P17-Gen-1> <64b48a7b-624c-26bd-be9b-0522fc490b28@huaweicloud.com> <1e77c538-d04b-62b7-a859-1589bab0ddef@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 08:40:24PM +0100, Jonas Oberhauser wrote: > > > On 1/23/2023 4:55 PM, Alan Stern wrote: > > I'm inclined to add this check to the memory model. Would you prefer to > > submit it yourself as a separate patch? Or are you happy to have it > > merged with my patch, and if so, do you have a final, preferred form for > > the check? > > After clearing my confusion, I'm no longer sure if it should be added. If > you're still inclined to have it, I would prefer to submit the patch, but > I'd like to define the use-cookie relation (= (data|[~Srcu-unlock];rfe)+) > and use it also to clarify the srcu match definition (I almost would like to > do that anyways :D). > Is that ok? Write up a patch and we can all judge it. Alan