Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1309462ybf; Thu, 27 Feb 2020 08:32:28 -0800 (PST) X-Google-Smtp-Source: APXvYqwaPLQo4Vrkm89OpxtMzg7HbJv/1s19oVAYiN2SS6EXgtAFLKzQalknq5ZX0VlsgHYED/qw X-Received: by 2002:aca:f487:: with SMTP id s129mr4120959oih.75.1582821147735; Thu, 27 Feb 2020 08:32:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582821147; cv=none; d=google.com; s=arc-20160816; b=cH30/CwwGRaFJIn7TDwAHdkj+noFIRoJE+Bf1p/6of4YKoXlv9ptWy90HpVs62KQlp J6rqkvGc44452S4Hy/u+vyzicv1DNUnTYEYvG4l/pfxQwh60JkJUYP7oPpZkN1KlgMAu UbmJLW7W+xii/mMl1XP5u0WZmIsU1NsLbtMAZFA0fUKOSrZVu0UGtGmXDRMbMb2Ed5mp yJWOZU7sprmdr87at+W0mLP3KO/Jc8pccGV2wKlUkSQk7cytIvjI92qwV2wNJnZvvHvY nRiZMXPqJi8rjnPx2DCCfoZSQ58RyIab/5x6rlISzGUh1H5MYp5lXQ4Srn4zXp8n2O0P hpkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=yoLSFwXFE6kBobFBsiwua6Kb0NcfYWprCgKgig1MYSM=; b=Nkkrr+S9Pi/MLsHbFUYMu+/I17/EUgLEka1Et/Zd5EJglGD9bRRjDy6cyGmib4TuKY 9CU16YnC9pzAra+FGbMDNeoJwWTgH+7yEcVvLhgkCv6ORZic6cnfurgJoYSiTPCfIzkw bZUynZtTNd+HdXv2kPsyKzNswY7a+/+75Ebnjxu98c0Zz/wyhE8WW6eAdY6ZEgYEex0e 6rZebTm17YHwUcjQFKzXtZItlx/TpwksHeL2XV25qovMgN20QjLQByT4qRAUTonloUTN wAaH0EjD8J1zhlzseJBKe+kNYf0K3XQAKRl5yUQiEc7lYNmYIa6m8RA7YBuR03NW1Udc cY8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l20si1879362otr.202.2020.02.27.08.32.15; Thu, 27 Feb 2020 08:32:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730134AbgB0QcM (ORCPT + 99 others); Thu, 27 Feb 2020 11:32:12 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:38776 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1730015AbgB0QcM (ORCPT ); Thu, 27 Feb 2020 11:32:12 -0500 Received: (qmail 3316 invoked by uid 2102); 27 Feb 2020 11:32:11 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Feb 2020 11:32:11 -0500 Date: Thu, 27 Feb 2020 11:32:11 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Boqun Feng cc: linux-kernel@vger.kernel.org, Andrea Parri , Will Deacon , Peter Zijlstra , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Daniel Lustig , Jonathan Corbet , Mauro Carvalho Chehab , "David S. Miller" , Rob Herring , Greg Kroah-Hartman , Jonathan Cameron , , Subject: Re: [PATCH v3 1/5] tools/memory-model: Add an exception for limitations on _unless() family In-Reply-To: <20200227004049.6853-2-boqun.feng@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 27 Feb 2020, Boqun Feng wrote: > According to Luc, atomic_add_unless() is directly provided by herd7, > therefore it can be used in litmus tests. So change the limitation > section in README to unlimit the use of atomic_add_unless(). Is this really true? Why does herd treat atomic_add_unless() different from all the other atomic RMS ops? All the other ones we support do have entries in linux-kernel.def. Alan PS: It seems strange to support atomic_add_unless but not atomic_long_add_unless. The difference between the two is trivial. > > Cc: Luc Maranget > Signed-off-by: Boqun Feng > --- > tools/memory-model/README | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/tools/memory-model/README b/tools/memory-model/README > index fc07b52f2028..409211b1c544 100644 > --- a/tools/memory-model/README > +++ b/tools/memory-model/README > @@ -207,11 +207,15 @@ The Linux-kernel memory model (LKMM) has the following limitations: > case as a store release. > > b. The "unless" RMW operations are not currently modeled: > - atomic_long_add_unless(), atomic_add_unless(), > - atomic_inc_unless_negative(), and > - atomic_dec_unless_positive(). These can be emulated > + atomic_long_add_unless(), atomic_inc_unless_negative(), > + and atomic_dec_unless_positive(). These can be emulated > in litmus tests, for example, by using atomic_cmpxchg(). > > + One exception of this limitation is atomic_add_unless(), > + which is provided directly by herd7 (so no corresponding > + definition in linux-kernel.def). atomic_add_unless() is > + modeled by herd7 therefore it can be used in litmus tests. > + > c. The call_rcu() function is not modeled. It can be > emulated in litmus tests by adding another process that > invokes synchronize_rcu() and the body of the callback >