Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp5273232rwn; Mon, 12 Sep 2022 06:54:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR6208u9jBPsB/j/DyjFI2XQAtnlOaiOmDlVVzG49x7WXEBpI94VH4DHiIZJ19krjVHbCC7s X-Received: by 2002:a17:907:2cce:b0:77a:6958:5aaa with SMTP id hg14-20020a1709072cce00b0077a69585aaamr9465436ejc.245.1662990875020; Mon, 12 Sep 2022 06:54:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662990875; cv=none; d=google.com; s=arc-20160816; b=ZeXVq5P9K2IaTT5L1gVZDjGRhgppkK8EsNhyS8pYK56qx/Wo147LJOrBu0oVCr/oTV fsAJC1jT8ZqK6gpwZoUfifbKbrukfRp0Id0lqD3CYy7UROaq55SzV8suuiAE2rUqXuoN ThRE8TnDecoTY2P+VxOnfTkY9ZGOO9QAOI1EZ1RbYtuebZjTkJYIVRMwpMJ/oI/MBn1Q +AK+QbwHBF8S/66YzlP72FSgr+2D9uE8rKQe3OF/wywc6K2QW5eYUWsaXL6JCD9wgpa1 oN8C4sX3ho5660+BIS4ixuea0/rEA/q8kKHYJWxkopGExtn0qejaUFrOZ9gylBWGcLOg /BGA== 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:dkim-signature; bh=nm9WbrH67w9L+VF1lN6eNZbJB8nMF8zkvtmxeZ0sJhU=; b=lkC6/IPML2BmGVrwD+3RMb7vEPPCP7jTT4GlpZHX6FfWBB64sy034gFwjIcra0AELn k7ld/YYkIwet+iSoc4+yzrbyFXRcVjVsHBfDJjypDbCLKpv4ezM5jqKhzm42Y/+m4GYg KeYxLe6rfvaAovAnsuP1u1135OZGiaVOdKPqBxGBRgMpfkWsaTfXh7M3Yx9AXfs8b8bR 9pdVnVmJrC5BHc+3C1IOUzVfWg4VcMIMsNFHIPaVCE9GEbuSMsOO9P16CudHs0Qn0NRE W+KWIeP79tM2bADoImX3EtIl6BOXn3eT7c0zJuejXxXDE4jAV3ncdnv2tOeKaaYEtlvd nwYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@in.tum.de header.s=20220209 header.b=jBRKDaSZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tum.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k26-20020aa7d8da000000b0044e95772e45si6578588eds.578.2022.09.12.06.54.10; Mon, 12 Sep 2022 06:54:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@in.tum.de header.s=20220209 header.b=jBRKDaSZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tum.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229817AbiILNjM (ORCPT + 99 others); Mon, 12 Sep 2022 09:39:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229759AbiILNjJ (ORCPT ); Mon, 12 Sep 2022 09:39:09 -0400 Received: from mailout3.rbg.tum.de (mailout3.rbg.tum.de [131.159.0.8]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EA021A3AB; Mon, 12 Sep 2022 06:39:07 -0700 (PDT) Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [131.159.254.14]) by mailout3.rbg.tum.de (Postfix) with ESMTPS id 0435B100374; Mon, 12 Sep 2022 15:39:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=in.tum.de; s=20220209; t=1662989941; bh=nm9WbrH67w9L+VF1lN6eNZbJB8nMF8zkvtmxeZ0sJhU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jBRKDaSZHuFx968kYxk+7LggHpxSVNm936kJ3LW3hvCu7FwCGQGfjrK5yNh0heYcc 5pS9rv1LpMZzEuHPlJTvxx3mVTT9dqLnSKAEbFnN+F4MZNPyIUXoBQQFkUobSFmMXT 7eXorTAUBlMzh1YBlc43rjMlk8KN9UL1upAW4gSMRmVnySeAElHubQaiSVBtLS+fkj nMp5xI12ejOWaf3J1ip2IWi9nGbFkFXIQSF9N9KDe6hY0wE1CkDgNukPNiyidY0Ofs 1CHoNbVpckJgWVgQ7KuWSsnuOv6n0LGCHRkZh00de7ybZ04MgLmyjqpp+Qop4S4NQr xaEHxCyaKzneA== Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id F3978542; Mon, 12 Sep 2022 15:39:00 +0200 (CEST) Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id C473E135; Mon, 12 Sep 2022 15:39:00 +0200 (CEST) Received: from mail.in.tum.de (vmrbg426.in.tum.de [131.159.0.73]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id BFF7E22; Mon, 12 Sep 2022 15:39:00 +0200 (CEST) Received: by mail.in.tum.de (Postfix, from userid 112) id BB5F84A0447; Mon, 12 Sep 2022 15:39:00 +0200 (CEST) Received: (Authenticated sender: heidekrp) by mail.in.tum.de (Postfix) with ESMTPSA id 49FCC4A018D; Mon, 12 Sep 2022 15:38:59 +0200 (CEST) (Extended-Queue-bit xtech_lh@fff.in.tum.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH v2] tools/memory-model: Weaken ctrl dependency definition in explanation.txt From: =?utf-8?Q?Paul_Heidekr=C3=BCger?= In-Reply-To: <20220912113838.GG246308@paulmck-ThinkPad-P17-Gen-1> Date: Mon, 12 Sep 2022 14:38:58 +0100 Cc: Alan Stern , Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Palmer Dabbelt , Michael Ellerman , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Marco Elver , Charalampos Mainas , Pramod Bhatotia , Soham Chakraborty , Martin Fink Content-Transfer-Encoding: quoted-printable Message-Id: <26A8E8E5-FA0B-4D5B-BDD1-3DA8E654965E@in.tum.de> References: <20220830210821.3763660-1-paul.heidekrueger@in.tum.de> <20220912113838.GG246308@paulmck-ThinkPad-P17-Gen-1> To: "Paul E. McKenney" X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12. Sep 2022, at 12:38, Paul E. McKenney wrote: > On Tue, Aug 30, 2022 at 09:08:20PM +0000, Paul Heidekr=C3=BCger wrote: >> The current informal control dependency definition in explanation.txt = is >> too broad and, as discussed, needs to be updated. >>=20 >> Consider the following example: >>=20 >>> if(READ_ONCE(x)) >>> return 42; >>>=20 >>> WRITE_ONCE(y, 42); >>>=20 >>> return 21; >>=20 >> The read event determines whether the write event will be executed = "at >> all" - as per the current definition - but the formal LKMM does not >> recognize this as a control dependency. >>=20 >> Introduce a new definition which includes the requirement for the = second >> memory access event to syntactically lie within the arm of a non-loop >> conditional. >>=20 >> Link: = https://lore.kernel.org/all/20220615114330.2573952-1-paul.heidekrueger@in.= tum.de/ >> Cc: Marco Elver >> Cc: Charalampos Mainas >> Cc: Pramod Bhatotia >> Cc: Soham Chakraborty >> Cc: Martin Fink >> Signed-off-by: Paul Heidekr=C3=BCger >> Co-developed-by: Alan Stern >=20 > Hearing no objections, I reverted the old version and replaced it > with this version. Thank you both! >=20 > Thanx, Paul Oh, wait, there was further discussion [1, 2], and we finally agreed on = [3]. So [3] is the final version. I think me sending a v2 immediately after the v1 led to this = out-of-order discussion - sorry! Many thanks, Paul [1]: = https://lore.kernel.org/all/663d568d-a343-d44b-d33d-29998bff8f70@joelferna= ndes.org/ [2]: = https://lore.kernel.org/all/D7E3D42D-2ABE-4D16-9DCA-0605F0C84F7D@in.tum.de= / [3]: = https://lore.kernel.org/all/20220903165718.4186763-1-paul.heidekrueger@in.= tum.de/ >> --- >>=20 >> v2: >> - Fix typos >> - Fix indentation of code snippet >>=20 >> v1: >> @Alan, since I got it wrong the last time, I'm adding you as a = co-developer after my >> SOB. I'm sorry if this creates extra work on your side due to you = having to >> resubmit the patch now with your SOB if I understand correctly, but = since it's >> based on your wording from the other thread, I definitely wanted to = give you >> credit. >>=20 >> tools/memory-model/Documentation/explanation.txt | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >>=20 >> diff --git a/tools/memory-model/Documentation/explanation.txt = b/tools/memory-model/Documentation/explanation.txt >> index ee819a402b69..0bca50cac5f4 100644 >> --- a/tools/memory-model/Documentation/explanation.txt >> +++ b/tools/memory-model/Documentation/explanation.txt >> @@ -464,9 +464,10 @@ to address dependencies, since the address of a = location accessed >> through a pointer will depend on the value read earlier from that >> pointer. >>=20 >> -Finally, a read event and another memory access event are linked by = a >> -control dependency if the value obtained by the read affects whether >> -the second event is executed at all. Simple example: >> +Finally, a read event X and another memory access event Y are linked = by >> +a control dependency if Y syntactically lies within an arm of an if, >> +else or switch statement and the condition guarding Y is either data = or >> +address-dependent on X. Simple example: >>=20 >> int x, y; >>=20 >> -- >> 2.35.1