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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0182C433E0 for ; Thu, 4 Mar 2021 15:37:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8476E64F02 for ; Thu, 4 Mar 2021 15:37:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231263AbhCDPgU (ORCPT ); Thu, 4 Mar 2021 10:36:20 -0500 Received: from netrider.rowland.org ([192.131.102.5]:58445 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S234692AbhCDPgF (ORCPT ); Thu, 4 Mar 2021 10:36:05 -0500 Received: (qmail 1613083 invoked by uid 1000); 4 Mar 2021 10:35:24 -0500 Date: Thu, 4 Mar 2021 10:35:24 -0500 From: Alan Stern To: "Paul E. McKenney" Cc: =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , bpf , LKML , parri.andrea@gmail.com, Will Deacon , Peter Zijlstra , boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com, joel@joelfernandes.org, Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , "Karlsson, Magnus" Subject: Re: XDP socket rings, and LKMM litmus tests Message-ID: <20210304153524.GA1612307@rowland.harvard.edu> References: <20210302211446.GA1541641@rowland.harvard.edu> <20210302235019.GT2696@paulmck-ThinkPad-P72> <20210303171221.GA1574518@rowland.harvard.edu> <20210303174022.GD2696@paulmck-ThinkPad-P72> <20210303202246.GC1582185@rowland.harvard.edu> <20210303220348.GL2696@paulmck-ThinkPad-P72> <20210304032101.GB1594980@rowland.harvard.edu> <20210304050407.GN2696@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210304050407.GN2696@paulmck-ThinkPad-P72> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Mar 03, 2021 at 09:04:07PM -0800, Paul E. McKenney wrote: > On Wed, Mar 03, 2021 at 10:21:01PM -0500, Alan Stern wrote: > > On Wed, Mar 03, 2021 at 02:03:48PM -0800, Paul E. McKenney wrote: > > > On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote: > > > > > And I cannot immediately think of a situation where > > > > > this approach would break that would not result in a data race being > > > > > flagged. Or is this yet another failure of my imagination? > > > > > > > > By definition, an access to a local variable cannot participate in a > > > > data race because all such accesses are confined to a single thread. > > > > > > True, but its value might have come from a load from a shared variable. > > > > Then that load could have participated in a data race. But the store to > > the local variable cannot. > > Agreed. My thought was that if the ordering from the initial (non-local) > load mattered, then that initial load must have participated in a > data race. Is that true, or am I failing to perceive some corner case? Ordering can matter even when no data race is involved. Just think about how much of the memory model is concerned with ordering of marked accesses, which don't participate in data races unless there is a conflicting plain access somewhere. Alan