Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp392878imw; Fri, 15 Jul 2022 05:30:09 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vCqod7WpyjTFUnKmacR4dsiIzQOVXjbUyZqFQNrbeNYP4wLx9ntC/32s7z3Imko6aynun3 X-Received: by 2002:a63:884:0:b0:412:9c83:47b1 with SMTP id 126-20020a630884000000b004129c8347b1mr11734379pgi.387.1657888209329; Fri, 15 Jul 2022 05:30:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657888209; cv=none; d=google.com; s=arc-20160816; b=EDF4EhgM7LP6TyawQNqtsYpDbXY/PqziYvgDS/LpVa6BepJ7gN8Na4V73CWVKddigu 91sU7158KbdYGbcxhSw56zzCUaj++zdyyoFQIoNRGEUYCl90t35ur+WJFD+iBuXNo+KH TkLJ5Qm/JKsL/11nM9uhbpdiVzhUP/Cc3yzbXxLXBhLPpxqqwOZbKqBFf6b9Uy7WtF5c hDIykcNsF1gDKnu/8b4at05e+pUxgB//npcupnl+G0iY5BfqxKQqRGPEH6PjndPxY7vn YxFkpHC/GxIEvs1hMAJbsKjZyG5hHEIlrMnzbBp50qLFmnQ5XhBzxNP0lH8jvMWODjLE TD4A== 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=zGE/jDIo1cfQsc+MnjdwsHIGgAF/4RlBe+yR6eNgnes=; b=rY2yx8gdcybWgDFM2g+KRM5IVkcEToJgEiIEBTREfMOnpKWOxx4+8ZxCg7oQQui+5v VwV+w5h5jQs7XZIC0E8Yf2TYUa8PGBqC5FappHizlRq3tRXfxsIRaCJDk67Lm9+JQ8BD WpVVrPT5setdeL8NyQ9EJyy4E9ClwY663PLbtw8+WOMfIiuXebGQZWWRq9IQXj6i8eg/ D9UE5AQv804YMGXh/7fSBVoSUrd63dFlzpL1jm+W+pnZlK/SWYZFHmG0YJs9fCW+p2CD JvZBR0yxc30Di8DwPhx+sq758le2dcru/dT6xiLkbzhWyl9XR8v7l6z8rzLA+TElqY4y 7yoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@in.tum.de header.s=20220209 header.b="Ry/i9d/z"; 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 y1-20020a170902ed4100b0016bc407e8ccsi627555plb.349.2022.07.15.05.29.52; Fri, 15 Jul 2022 05:30:09 -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="Ry/i9d/z"; 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 S231954AbiGOM1h (ORCPT + 99 others); Fri, 15 Jul 2022 08:27:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229782AbiGOM1e (ORCPT ); Fri, 15 Jul 2022 08:27:34 -0400 Received: from mailout1.rbg.tum.de (mailout1.rbg.tum.de [131.159.0.201]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F6C3820D1; Fri, 15 Jul 2022 05:27:33 -0700 (PDT) Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [131.159.254.14]) by mailout1.rbg.tum.de (Postfix) with ESMTPS id 6FD8F98; Fri, 15 Jul 2022 14:27:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=in.tum.de; s=20220209; t=1657888050; bh=zGE/jDIo1cfQsc+MnjdwsHIGgAF/4RlBe+yR6eNgnes=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ry/i9d/zyiTV+xWdRYvKVN/SbuXo5p5zNUtP2m5Y8UgSv5RQQydATc1Paj2mXm2r4 hphlL3ROKc3e2BtI/OO2ZbCQKKLOzjKOQ62oSrq3PTMKIdB8D3SD2BV/aPonr531i3 1YGQoZpNQqVXnlKQ0rexqAUQUH61WXoPOce1qJpBcnrycK8PSoD5k8BAB81YOq+GKT MxV4uJhGqbHNvANs1HSE6pS/POjflssPArH4K9ALazQs1FFwnrVhI7rx6q5Pw1hO2N qHTfUmvDgXZzei3loZ6anYsqkJBH2Etf2xbhARMR3W0blbU71woE8jtsDdXJ4M33V+ 5nuy5w85gsfCA== Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id 6E438DD0; Fri, 15 Jul 2022 14:27:30 +0200 (CEST) Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 404A4DCD; Fri, 15 Jul 2022 14:27:30 +0200 (CEST) Received: from mail.in.tum.de (mailproxy.in.tum.de [IPv6:2a09:80c0::78]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id 3B74B5B5; Fri, 15 Jul 2022 14:27:30 +0200 (CEST) Received: by mail.in.tum.de (Postfix, from userid 112) id 355A54A0215; Fri, 15 Jul 2022 14:27:30 +0200 (CEST) Received: (Authenticated sender: heidekrp) by mail.in.tum.de (Postfix) with ESMTPSA id 3B3BB4A0129; Fri, 15 Jul 2022 14:27:29 +0200 (CEST) (Extended-Queue-bit xtech_mr@fff.in.tum.de) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH RFC] tools/memory-model: Adjust ctrl dependency definition From: =?utf-8?Q?Paul_Heidekr=C3=BCger?= In-Reply-To: Date: Fri, 15 Jul 2022 14:27:28 +0200 Cc: clang-built-linux , linux-toolchains@vger.kernel.org, Andrea Parri , Will Deacon , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Nathan Chancellor , Nick Desaulniers , Tom Rix , Palmer Dabbelt , LKML , linux-arch , Marco Elver , Charalampos Mainas , Pramod Bhatotia , Soham Chakraborty , Martin Fink Content-Transfer-Encoding: quoted-printable Message-Id: <20F4C097-24B4-416B-95EE-AC11F5952B44@in.tum.de> References: <20220615114330.2573952-1-paul.heidekrueger@in.tum.de> <50B9D7C1-B11D-4583-9814-BFFF2C80D8CA@in.tum.de> <04B4DBD6-1262-4905-9E85-9466FC104895@in.tum.de> To: Alan Stern X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS 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 Alan Stern wrote: > On Mon, Jun 27, 2022 at 11:47:43AM +0200, Paul Heidekr=C3=BCger wrote: >>> On 21. Jun 2022, at 16:24, Alan Stern = wrote: >>>=20 >>> On Tue, Jun 21, 2022 at 01:59:27PM +0200, Paul Heidekr=C3=BCger = wrote: >>>> OK. So, LKMM limits the scope of control dependencies to its = arm(s), hence >>>> there is a control dependency from the last READ_ONCE() before the = loop >>>> exists to the WRITE_ONCE(). >>>>=20 >>>> But then what about the following: >>>>=20 >>>>> int *x, *y; >>>>>=20 >>>>> int foo() >>>>> { >>>>> /* More code */ >>>>>=20 >>>>> if(READ_ONCE(x)) >>>>> return 42; >>>>>=20 >>>>> /* More code */ >>>>>=20 >>>>> WRITE_ONCE(y, 42); >>>>>=20 >>>>> /* More code */ >>>>>=20 >>>>> return 0; >>>>> } >>>>=20 >>>> The READ_ONCE() determines whether the WRITE_ONCE() will be = executed at all, >>>> but the WRITE_ONCE() doesn't lie in the if condition's arm. >>>=20 >>> So in this case the LKMM would not recognize that there's a control=20= >>> dependency, even though it clearly exists. >>=20 >> Oh, that's unfortunate. >>=20 >> Then I would still argue that the "at all" definition is misleading. = This >=20 > I agree, and I would welcome a patch improving the definition. Perhaps=20= > something along the lines of what I wrote earlier in this email = thread. I have just been thinking about how to word this patch; am I correct in assuming that the LKMM does not deal with loop conditions? Or in other words, there is no way for a loop condition to impose a ctrl dependency = on any WRITE_ONCE's in the loop body? It are only if and switch statements = the LKMM is concerned with in the case of ctrl dependencies? Many thanks, Paul >> time in the other direction as I had initially proposed though, as = the above >> example is a case where "at all" holds true, but LKMM doesn't cover = it. Or >> do you think that caveating this in litmus-tests.txt, e.g. via the = patch we >> had recently worked out [1], is enough? >=20 > No, the explanation should be improved. >=20 > Alan