Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1325481ybf; Thu, 27 Feb 2020 08:50:43 -0800 (PST) X-Google-Smtp-Source: APXvYqzJWlANjL0lNgXNMgAtyC0G3hp4mRtzdnz6l0nEatPtF+VsgvbFraI51YsGQafn4Z41ChMf X-Received: by 2002:aca:4d82:: with SMTP id a124mr2383953oib.103.1582822243301; Thu, 27 Feb 2020 08:50:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582822243; cv=none; d=google.com; s=arc-20160816; b=m8bQwuBo+Wa7q99/GVG65j6D0kh4ygBE3/Zlgk99mxFMCbzik3zQE6IJQp22yTQGIp WVuk7i3Rmvr2fKDlFhT2lIQZcR63RZXjxKSLlfkfWGUMiykAmbhBtGk5iYt6pH8idt7T 3hvjkce15EScRScJ32TTdpEvhO/J/GFRcwzXSi+/LgZixzfCW/nwJcCocOtLe/2Ertui 21c9YtZpktlSK+4njToYZ7AKx9XSQJBlTmwa9sBWMBxNF4u9SrzAbvPMdnsyOpcHk5zC oqFXA6POBWtKpSy+T7GLLpSeE3CBI3T9yQ+f/ZVWDPiVR+8TeuusWwy6m90FR4IINIo2 Z7bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:from; bh=f6LK9H46CydV4fnyU0PvqymF3yfPAtohirOGh9nw004=; b=sb1DkA0g5jy4s8jbvC1873WhAc9eDLnwLa32bFJp6cTXQ8RGkmNETAxUDCmOfxpL6M DiRtYofi5EqWSqInxgYpuvMCiSohi6rnmDvcbdaPlv8z9TWXbC9KZDt01m266d3HDdVY Kt+MEM1MmKgRTNQ3ny4JHrNuRBvY9sH+qssU9ZzdSbhjTXt7qfMjEfal+YxdTTcly2fz ugy/dcwj4KyuRTlVVbbeBOVGQdl338i4CvBYPLp/xF0sJqjz0fvjkaQf2xYkw1+KN792 KPDEWMMZ+WtPtozPcY2R+KcmfXOV3TJyIMTPouTi2lKm4eJ90fQOqbAjLmhPKkUz69b4 yezg== 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 g17si2165047otg.129.2020.02.27.08.50.29; Thu, 27 Feb 2020 08:50:43 -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 S1730500AbgB0QtE (ORCPT + 99 others); Thu, 27 Feb 2020 11:49:04 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:29038 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730194AbgB0QtE (ORCPT ); Thu, 27 Feb 2020 11:49:04 -0500 From: Luc Maranget X-IronPort-AV: E=Sophos;i="5.70,492,1574118000"; d="scan'208";a="437938070" Received: from yquem.paris.inria.fr (HELO yquem.inria.fr) ([128.93.101.33]) by mail2-relais-roc.national.inria.fr with ESMTP; 27 Feb 2020 17:49:02 +0100 Received: by yquem.inria.fr (Postfix, from userid 18041) id 065F9E1AAB; Thu, 27 Feb 2020 17:49:02 +0100 (CET) Date: Thu, 27 Feb 2020 17:49:02 +0100 To: Alan Stern Cc: Boqun Feng , 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 , linux-arch@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v3 1/5] tools/memory-model: Add an exception for limitations on _unless() family Message-ID: <20200227164901.jxwk26ey3i2n2yhu@yquem.inria.fr> References: <20200227004049.6853-2-boqun.feng@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) 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. I think this to be true :) As far as I remember atomic_add_unless is quite different fron other atomic RMW ops and called for a specific all-OCaml implementation, without an entry in linux-kernel.def. As to atomic_long_add_unless, I was not aware of its existence. --Luc > > 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 > >