Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1130642pxb; Thu, 4 Mar 2021 04:14:16 -0800 (PST) X-Google-Smtp-Source: ABdhPJw5//sTkpSkmMTZFSkXECbZ2HNFXXaD2IH1Wgi/Flx1riM+hn4wE93yeyKxw7ocgY+7oA9d X-Received: by 2002:aa7:ccd7:: with SMTP id y23mr4012066edt.190.1614860056485; Thu, 04 Mar 2021 04:14:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614860056; cv=none; d=google.com; s=arc-20160816; b=dTFv1dPlJtb/i2Ft4XybHbg0W6vItBBZvepHfjVKO7+WYx0AtTZ2ejeSCe4PEaiQcq NnCaBqqig1mXUR4IRTVa3GKxX+ZCvVj1WdS6V0GlqenqjaQPpfhzIE4uEFSinnNuQ7Bm PuJWokSQAVIyL0mxheTQvTZJAkbQj2cGftvmb/1rVREwSvrGiJWTVT8cVZoGv0oLJaPK yKTZob7m6V5BmJ+U6qcDuoPTaOMc/ZuU1C1jX1EjaRm/VR6IX7q9hkF+Wy1aBtkPh7Vg FxRCNFibNrqaxtZIS31jEs6a8feA0f12HdcZhfXhqIf9eeusQgjochKHOGIeCKgkwIsK y1uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=F1yxe4NxLpI2sISNaKYP2JXKVeuGtwbbu/wkZRtd+IA=; b=SYCPDsX5ZJ9eEyMKcySQm2PJSIMUhKv+yDDvag2G16rmd/v77yYnWoxzjaIHfewdh4 Nbdj3KJVbs8pW6SYRabMKcQPQiEznXJRAfbsuo7+I+E0kizrsxr9Fc7ks/0q9yrDfIpL ivKYf8z4iUC+VUNT7e5t+twr7gIEP0IzOJXVL8RmbG9huud6dAb/+NV2fySG3hP8LrR3 q7/kQK6CZWsyeLt4mK7zJqqVtMMerHwWCofbLN2KCU+9CVXjlwvrYgvl+fos80HzNimC /sO1kZifB3+1d2HKHjwQIDZxaz7crlQgb2u0+YfFP3ngGo3IQuYWkgkPx+KrpdvQZqbs AzyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g3si5274490edp.527.2021.03.04.04.13.53; Thu, 04 Mar 2021 04:14:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1580488AbhCCSeQ (ORCPT + 99 others); Wed, 3 Mar 2021 13:34:16 -0500 Received: from netrider.rowland.org ([192.131.102.5]:42275 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S237876AbhCCRN4 (ORCPT ); Wed, 3 Mar 2021 12:13:56 -0500 Received: (qmail 1576769 invoked by uid 1000); 3 Mar 2021 12:12:21 -0500 Date: Wed, 3 Mar 2021 12:12:21 -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: <20210303171221.GA1574518@rowland.harvard.edu> References: <20210302211446.GA1541641@rowland.harvard.edu> <20210302235019.GT2696@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210302235019.GT2696@paulmck-ThinkPad-P72> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 02, 2021 at 03:50:19PM -0800, Paul E. McKenney wrote: > On Tue, Mar 02, 2021 at 04:14:46PM -0500, Alan Stern wrote: > > This result is wrong, apparently because of a bug in herd7. There > > should be control dependencies from each of the two loads in P0 to each > > of the two stores, but herd7 doesn't detect them. > > > > Maybe Luc can find some time to check whether this really is a bug and > > if it is, fix it. > > I agree that herd7's control dependency tracking could be improved. > > But sadly, it is currently doing exactly what I asked Luc to make it do, > which is to confine the control dependency to its "if" statement. But as > usual I wasn't thinking globally enough. And I am not exactly sure what > to ask for. Here a store to a local was control-dependency ordered after > a read, and so that should propagate to a read from that local variable. > Maybe treat local variables as if they were registers, so that from > herd7's viewpoint the READ_ONCE()s are able to head control-dependency > chains in multiple "if" statements? > > Thoughts? Local variables absolutely should be treated just like CPU registers, if possible. In fact, the compiler has the option of keeping local variables stored in registers. (Of course, things may get complicated if anyone writes a litmus test that uses a pointer to a local variable, Especially if the pointer could hold the address of a local variable in one execution and a shared variable in another! Or if the pointer is itself a shared variable and is dereferenced in another thread!) But even if local variables are treated as non-shared storage locations, we should still handle this correctly. Part of the problem seems to lie in the definition of the to-r dependency relation; the relevant portion is: (dep ; [Marked] ; rfi) Here dep is the control dependency from the READ_ONCE to the local-variable store, and the rfi refers to the following load of the local variable. The problem is that the store to the local variable doesn't go in the Marked class, because it is notated as a plain C assignment. (And likewise for the following load.) Should we change the model to make loads from and stores to local variables always count as Marked? What should have happened if the local variable were instead a shared variable which the other thread didn't access at all? It seems like a weak point of the memory model that it treats these two things differently. Alan