Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4399CC05027 for ; Fri, 3 Feb 2023 20:19:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232999AbjBCUTm (ORCPT ); Fri, 3 Feb 2023 15:19:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233013AbjBCUTk (ORCPT ); Fri, 3 Feb 2023 15:19:40 -0500 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11B239D58A for ; Fri, 3 Feb 2023 12:19:39 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id w3so6853766qts.7 for ; Fri, 03 Feb 2023 12:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PlO+7yJUL6nZz6lWyKAteQU74Ju3H8abrNP72ihWCAM=; b=Kmqgxr98A8rmlt1eG1Qvlry8R2htsdd8gpZ6xlaKDfwShmcldtpeNwAwBl+zru4UHO EjSIuyi/1gvQIqauWKxF1u9onlcTqDp2tfx7qNRK4/Y3nKJ9VCvqtvFoKH9iEkIm9TtH lMJWMucq5G4qzkWScRZDtPT9ns3GVif+j0OXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PlO+7yJUL6nZz6lWyKAteQU74Ju3H8abrNP72ihWCAM=; b=CJoWrAK4jHbZO6v+QxIEb5a+74f9kn3CuoNr9v1uOHmn1Xke8/MCSrfpDTp8GPFffs 6ZK7nORyqjYQQX25/DAV6CJmpaOMQ2VbvSgxE3wZhBfdi0APqJ2dVp2EeDrO2dSY8qy4 dvZ/3TDPkBCBXkdY4rgEV3GgfcwmlBrzGlc8Z8rNqRKxicteSuVZ/cU2MV5s1244kUje Tshuc5rwfrAkynHFyw3Vt2OuZbBhJN3OGifUgmifI2+u7m/EyknqDAEYytclbcufCGD8 pmJy8n81Skw833sNh6DlQDUinz7gAaJfAgrLnxiitgDjOXEPE5kgWXzRdxNU28xJN5gV 4q2g== X-Gm-Message-State: AO0yUKVp0HmNW4M8bmfEAgo1dLwmwWNbO0O0a/sySG6R2rK4N/OVP9Ia ivVKWueYUcov9FD8zVNd3ldUiIC2uhhmv4mI X-Google-Smtp-Source: AK7set9nC+TUlWirAN+jtujA8yCUlYb0urmBCrtJgYrW0olrJKhCm4nX/TVN2h+LCT26hzgcod7jnQ== X-Received: by 2002:ac8:7e86:0:b0:3b9:a641:aa66 with SMTP id w6-20020ac87e86000000b003b9a641aa66mr21897622qtj.15.1675455577457; Fri, 03 Feb 2023 12:19:37 -0800 (PST) Received: from joelboxx.c.googlers.com.com (129.239.188.35.bc.googleusercontent.com. [35.188.239.129]) by smtp.gmail.com with ESMTPSA id g17-20020ae9e111000000b006ce580c2663sm2457424qkm.35.2023.02.03.12.19.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 12:19:36 -0800 (PST) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Akira Yokosawa , Alan Stern , Andrea Parri , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , linux-arch@vger.kernel.org, Luc Maranget , Nicholas Piggin , "Paul E. McKenney" , Peter Zijlstra , Will Deacon Subject: [PATCH RFC] tools/memory-model: Restrict to-r to read-read address dependency Date: Fri, 3 Feb 2023 20:19:13 +0000 Message-Id: <20230203201913.2555494-1-joel@joelfernandes.org> X-Mailer: git-send-email 2.39.1.519.gcb327c4b5f-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org During a code-reading exercise of linux-kernel.cat CAT file, I generated a graph to show the to-r relations. While likely not problematic for the model, I found it confusing that a read-write address dependency would show as a to-r edge on the graph. This patch therefore restricts the to-r links derived from addr to only read-read address dependencies, so that read-write address dependencies don't show as to-r in the graphs. This should also prevent future users of to-r from deriving incorrect relations. Note that a read-write address dep, obviously, still ends up in the ppo relation via the to-w relation. I verified that a read-read address dependency still shows up as a to-r link in the graph, as it did before. For reference, the problematic graph was generated with the following command: herd7 -conf linux-kernel.cfg \ -doshow dep -doshow to-r -doshow to-w ./foo.litmus -show all -o OUT/ Signed-off-by: Joel Fernandes (Google) --- tools/memory-model/linux-kernel.cat | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/memory-model/linux-kernel.cat b/tools/memory-model/linux-kernel.cat index d70315fddef6..26e6f0968143 100644 --- a/tools/memory-model/linux-kernel.cat +++ b/tools/memory-model/linux-kernel.cat @@ -69,7 +69,7 @@ let dep = addr | data let rwdep = (dep | ctrl) ; [W] let overwrite = co | fr let to-w = rwdep | (overwrite & int) | (addr ; [Plain] ; wmb) -let to-r = addr | (dep ; [Marked] ; rfi) +let to-r = (addr ; [R]) | (dep ; [Marked] ; rfi) let ppo = to-r | to-w | fence | (po-unlock-lock-po & int) (* Propagation: Ordering from release operations and strong fences. *) -- 2.39.1.519.gcb327c4b5f-goog