Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1134662pxb; Thu, 4 Mar 2021 04:21:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKYA5JpkKpO3ZTugUnyRAeEYpOUzAKiEZ3c7lphfqN9KsCSjJTZ6phYxHC7sp/WfLyzlcI X-Received: by 2002:aa7:d954:: with SMTP id l20mr4005053eds.1.1614860462500; Thu, 04 Mar 2021 04:21:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614860462; cv=none; d=google.com; s=arc-20160816; b=usleSm2EJYHCsqqLsUdx2AHyW16XLPzNd1vjDNtO/cA0mdlFPs1m6lyWpmZ94IisIO GIafz/fF8YNcHm91msK1OTE01Od2+pcnk1ILRntQd84RGpwOXKlGUYgrpZY1mTfmV4g3 Txeq/HK45wt27ZaG2noXfURSDfNRHmhRH+ezGV87w51YAiUlTVBQZs57IsyEkqbr/0Bp VnWjfLKAyfNg5t1Np7QXOL+YSNOMn3vKUf5g+tAoQjHRnn0jCK2H9k72hLlmJB6uBrBm 02gV8IvKQJbXgxEWJuBw8We9OOiFd2wL3Or3tnA+UPAdXHvvFKrTyKe+YhrBz9t+1Egi CLBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=2xffRHtM6woa250RCs3jb+uxnwWO11FMdHNTWANjkAY=; b=mU5D93YDGLw7P1QZZPIlrfgFd2wk9m8EOKyD0t9HQ0H+HOn2Gv5dREwtO2MLY92C1G y0YUyoUmu3BfgnlXg1uVo41widCjStRpA+MbOcr422uxhTvkABfdBHJNlowCz/hWmt90 T8N2CS/evpWw/NLNqyCBXaMAIJiQGTWVPN2GafkK6ME1EKlnGrvEZ8N6jeQq2apUbhCX hBfDbyxTb3wzBTaAnw6NxyoVqqcUJnqMZDZZmbrtn+wtVOYNDYv1Dpj6M8RBPhrygqit NkpjAXf7rSuA4W2j03JXP5+08jmGOuEDZWg4KSNebmLABWC12K/kpLa7MLrPlTpCnGex Bn+w== 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 se21si12645886ejb.558.2021.03.04.04.20.40; Thu, 04 Mar 2021 04:21:02 -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 S1836048AbhCCSrL convert rfc822-to-8bit (ORCPT + 99 others); Wed, 3 Mar 2021 13:47:11 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:35025 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236532AbhCCRjp (ORCPT ); Wed, 3 Mar 2021 12:39:45 -0500 X-IronPort-AV: E=Sophos;i="5.81,220,1610406000"; d="scan'208";a="495963342" Received: from lfbn-idf1-1-708-183.w86-245.abo.wanadoo.fr (HELO mp-66156.home) ([86.245.159.183]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 18:37:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: XDP socket rings, and LKMM litmus tests From: maranget In-Reply-To: <20210303171221.GA1574518@rowland.harvard.edu> Date: Wed, 3 Mar 2021 18:37:36 +0100 Cc: "Paul E. McKenney" , =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= , 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, akiyks@gmail.com, dlustig@nvidia.com, joel@joelfernandes.org, =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , "Karlsson, Magnus" Content-Transfer-Encoding: 8BIT Message-Id: <29736B0B-9960-473C-85BB-5714F181198B@inria.fr> References: <20210302211446.GA1541641@rowland.harvard.edu> <20210302235019.GT2696@paulmck-ThinkPad-P72> <20210303171221.GA1574518@rowland.harvard.edu> To: Alan Stern X-Mailer: Apple Mail (2.3654.60.0.2.21) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On 3 Mar 2021, at 18:12, Alan Stern wrote: > > 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. > And indeed local variables are treated as registers by herd7. > (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: In fact, I’d rather change the computation of “dep” here control-dependency “ctrl”. Notice that “ctrl” is computed by herd7 and present in the initial environment of the Cat interpreter. I have made a PR to herd7 that performs the change. The commit message states the new definition. > > (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.) > This is a related issue, I am not sure, but perhaps it can be formulated as "should rfi and rf on registers behave the same?” > 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