Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp8040956rwn; Wed, 14 Sep 2022 08:08:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR7BY2dbzLyCfYA3VL/rmqyHv+mK87Fai89YymUg/8HZd1d50HjwAOoDT3Hk0d44JmiDd+Ys X-Received: by 2002:a05:6402:33c5:b0:447:e4a3:c930 with SMTP id a5-20020a05640233c500b00447e4a3c930mr30972155edc.401.1663168081455; Wed, 14 Sep 2022 08:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663168081; cv=none; d=google.com; s=arc-20160816; b=zcBz0oUa9mKZ3amMsuOoHS9EzDe0wiSMLrJ3bVbWtQ7SXfW1VxVMVAXOV5MIc4AZP9 me4INsba+7SIvSkzPsnZaQ4+cwbwLk/zyxrEMpq2nWdfyePAeBkRkPA3+oOuvgQqzliv M7wVubJ79boVbxpjl+5EQlbbuWrBcvFvlnstdrCqH29EMF2DH/mRGjrqNlq3AMbzS5Nn rBQs0MLVjEvyX+/gFJ45LGtFGliun4Pyp1mFLPBp+/V5AkJt3p4GbtbcOxkceg2v86QM 78UjldcY2tyatOOjCAPt9hHkwZIxXRQE2V9Kf4xgogPgjow7FqRT5Jp8kkR42dTmFjZq M7+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Y4x83TAno+A31nURnWOUZ1d2HDVtgur168y04Oc6ioU=; b=MACp4IyIGsoIa8cRqsWh+SIEwWMH/L4KUn1IAhkLG4SF56pEPzjnFknkjRiBvdWN/a d5qQhwr3g2huS2JWsyiny+KNSm9KJA+so+ACpjw7K0nWJ/kUnSNyRWRuO8UT2WBsAvGv LS/HPrjvHx7VQwf39Utb58HDDCXVoksLudfpjFpfvKjqT9FiZsvHNkrIoMGS2BGMJd/h UxDIQuox3RWDGUyaMK33qIxMnzV/OHt1VQagAsZ7oTi32wzvSi6yeKGa9cPMY2YfMB9c 5vn7ddUvOq9V4kVJ5e3K8oLwAPUUf+rGYj18LHv3PDODzEZ8WS28DX0KMoPCIJkHRAg0 deVQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id di22-20020a170906731600b007307f95bc5dsi12907350ejc.383.2022.09.14.08.07.34; Wed, 14 Sep 2022 08:08:01 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229615AbiINOlh (ORCPT + 99 others); Wed, 14 Sep 2022 10:41:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229688AbiINOld (ORCPT ); Wed, 14 Sep 2022 10:41:33 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 667C55C9EB for ; Wed, 14 Sep 2022 07:41:32 -0700 (PDT) Received: (qmail 640842 invoked by uid 1000); 14 Sep 2022 10:41:31 -0400 Date: Wed, 14 Sep 2022 10:41:31 -0400 From: Alan Stern To: Hernan Luis Ponce de Leon Cc: Jonas Oberhauser , Joel Fernandes , Boqun Feng , Peter Zijlstra , "Paul E. McKenney" , "parri.andrea@gmail.com" , "will@kernel.org" , "npiggin@gmail.com" , "dhowells@redhat.com" , "j.alglave@ucl.ac.uk" , "luc.maranget@inria.fr" , "akiyks@gmail.com" , "dlustig@nvidia.com" , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" Subject: Re: "Verifying and Optimizing Compact NUMA-Aware Locks on Weak Memory Models" Message-ID: References: <674d0fda790d4650899e2fcf43894053@huawei.com> <34735a476c3b4913985de3403a6216bd@huawei.com> <7ad2354bf993435b917f278d4199a6ff@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ad2354bf993435b917f278d4199a6ff@huawei.com> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no 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 Mon, Sep 12, 2022 at 11:10:17AM +0000, Hernan Luis Ponce de Leon wrote: > I think it is somehow possible to show the liveness violation using herd7 and the following variant of the code > > ------------------------------------------------------------------------ > C Liveness > { > atomic_t x = ATOMIC_INIT(0); > atomic_t y = ATOMIC_INIT(0); > } > > > P0(atomic_t *x) { > // clear_pending_set_locked > int r0 = atomic_fetch_add(2,x) ; > } > > P1(atomic_t *x, int *z, int *y) { > // this store breaks liveness > WRITE_ONCE(*y, 1); > // queued_spin_trylock > int r0 = atomic_read(x); > // barrier after the initialisation of nodes > smp_wmb(); > // xchg_tail > int r1 = atomic_cmpxchg_relaxed(x,r0,42); > // link node into the waitqueue > WRITE_ONCE(*z, 1); > } > > P2(atomic_t *x,int *z, int *y) { > // node initialisation > WRITE_ONCE(*z, 2); > // queued_spin_trylock > int r0 = atomic_read(x); > // barrier after the initialisation of nodes > smp_wmb(); > // if we read z==2 we expect to read this store > WRITE_ONCE(*y, 0); > // xchg_tail > int r1 = atomic_cmpxchg_relaxed(x,r0,24); > // spinloop > int r2 = READ_ONCE(*y); > int r3 = READ_ONCE(*z); > } > > exists (z=2 /\ y=1 /\ 2:r2=1 /\ 2:r3=2) > ------------------------------------------------------------------------ > > Condition "2:r3=2" forces the spinloop to read from the first write in P2 and "z=2" forces this write > to be last in the coherence order. Conditions "2:r2=1" and "y=1" force the same for the other read. > herd7 says this behavior is allowed by LKMM, showing that liveness can be violated. > > In all the examples above, if we use mb() instead of wmb(), LKMM does not accept > the behavior and thus liveness is guaranteed. That's right. The issue may be somewhat confused by the fact that there have been _two_ separate problems covered in this discussion. One has to do with the use of relaxed vs. non-relaxed atomic accesses, and the other -- this one -- has to do with liveness (eventual termination of a spin loop). You can see the distinction quite clearly by noticing in the litmus test above, the variable x plays absolutely no role. There are no dependencies from it, it isn't accessed by any instructions that include an acquire or release memory barrier, and it isn't used in the "exists" clause. If we remove x from the test (and remove P0, which is now vacuous), and we also remove the unneeded reads at the end of P2 (unneeded because they observe the co-final values stored in y and z), what remains is: P1(int *z, int *y) { WRITE_ONCE(*y, 1); smp_wmb(); WRITE_ONCE(*z, 1); } P2(int *z, int *y) { WRITE_ONCE(*z, 2); smp_wmb(); WRITE_ONCE(*y, 0); } exists (z=2 /\ y=1) which is exactly the 2+2W pattern. As others have pointed out, this pattern is permitted by LKML because we never found a good reason to forbid it, even though it cannot occur on any real hardware that supports Linux. On the other hand, the simplicity of this "liveness" test leads me to wonder if it isn't missing some crucial feature of the actual qspinlock implementation. Alan