Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp3033344ybv; Sat, 15 Feb 2020 09:14:21 -0800 (PST) X-Google-Smtp-Source: APXvYqxLZgscoA3gYFpBlZ5KQ4ubSfRd8/xt/nIXoMQVP+Vyty1IjHZnEWhtfaWYicrU9IegSLeD X-Received: by 2002:a05:6830:50:: with SMTP id d16mr6572381otp.166.1581786861589; Sat, 15 Feb 2020 09:14:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581786861; cv=none; d=google.com; s=arc-20160816; b=KLuOM1Jr8U5ojR1gU5MVO2v413iMLZENjNFPSSUoctHxpt6RZpC/72S9LUGt1ywKhD RLLWd6TdUjJ+HBLP046uD4YuPAA7+DjYZTw8BTEfUVzL6/tCPSIWpXR+clELY5wTQQng SuLrFm+iPAF/o/yp3DTsGFEcCWFdB/iPNYZ6PeZ8vAv3K78xMKC0iQiX61uhtIgNfT4v WfG5+qbUaeujTPeE+EZDK3XWpe/tnCYx+iq8dtcex8NfjwxZz1UKy1byez/DbepQ/fV6 AzwfZebVrOnDFBtHQjap5IPN8m1iNR1JYiR7Q++qeecUa195AZuFqGj0TJ3CMf6YbYNU tsXA== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=ojOGN8EiYk608AQyfOP0NuNTFuiMq59oHkOZfeL3lrA=; b=pkIUj6OdZ5d21At4zSioETzawfs10sj7TAbdBvphPEPEqxgf2VxRy1vMxy9O6AI3sR 2capBagSQy2Eo+0JhaaRgwlK5CBWu0Uk+LzznJnnyhGDhdF1p4yp/qOXrmjDGfjex9Hs 3xAsWEdp+BO8OuiIhA5KXqntnHzq4sSyXhcxww+M586bkldBTmqNTg9Gzg3gzt3ZEhqI po9UoF0+zH7+wjdtKfCLZIpKqXvvl070opj/kUSBidg0RnaeJ0za146KeR//BHr4kbQv OTcQwVoeHk8m2OdJ6Gj060sKfYTxQY7zu6TJuosgafBCop8g5NYQCXJYaGLlCicqN1rL sczg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OD6SuASq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k184si4043379oib.239.2020.02.15.09.14.09; Sat, 15 Feb 2020 09:14:21 -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; dkim=pass header.i=@kernel.org header.s=default header.b=OD6SuASq; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726477AbgBORNc (ORCPT + 99 others); Sat, 15 Feb 2020 12:13:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:55258 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726254AbgBORNb (ORCPT ); Sat, 15 Feb 2020 12:13:31 -0500 Received: from paulmck-ThinkPad-P72.home (smb-adpcdg2-04.hotspot.hub-one.net [213.174.99.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF00D24676; Sat, 15 Feb 2020 17:13:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581786811; bh=5l8Vi8hleqqzVtD4lt7Lj3hIV69+fYnulxZp4qYnC7Q=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=OD6SuASqhLkiSk3WfOyp1pmpybaGcqpvStW+3m4XqP2l9Lb3Xu7kZVMTXPOL8162t MKy04wUvMR2KxNoCJtdGNkCGGMQsY5xZQ3+DqZnb9X38qnicVnNwv3rsXlrH3M2eo7 69MW/dngshLWwqZ3/ULZG9SY1qsKhIa0e3SvNja8= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id E84FE35219C1; Sat, 15 Feb 2020 07:25:50 -0800 (PST) Date: Sat, 15 Feb 2020 07:25:50 -0800 From: "Paul E. McKenney" 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 , Akira Yokosawa , Daniel Lustig , Jonathan Corbet , linux-arch@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [RFC 0/3] tools/memory-model: Add litmus tests for atomic APIs Message-ID: <20200215152550.GA13636@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200214040132.91934-1-boqun.feng@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 14, 2020 at 10:27:44AM -0500, Alan Stern wrote: > On Fri, 14 Feb 2020, Boqun Feng wrote: > > > A recent discussion raises up the requirement for having test cases for > > atomic APIs: > > > > https://lore.kernel.org/lkml/20200213085849.GL14897@hirez.programming.kicks-ass.net/ > > > > , and since we already have a way to generate a test module from a > > litmus test with klitmus[1]. It makes sense that we add more litmus > > tests for atomic APIs into memory-model. > > It might be worth discussing this point a little more fully. The > set of tests in tools/memory-model/litmus-tests/ is deliberately rather > limited. Paul has a vastly more expansive set of litmus tests in a > GitHub repository, and I am doubtful about how many new tests we want > to keep in the kernel source. Indeed, the current view is that the litmus tests in the kernel source tree are intended to provide examples of C-litmus-test-language features and functions, as opposed to exercising the full cross-product of Linux-kernel synchronization primitives. For a semi-reasonable subset of that cross-product, as Alan says, please see https://github.com/paulmckrcu/litmus. For a list of the Linux-kernel synchronization primitives currently supported by LKMM, please see tools/memory-model/linux-kernel.def. > Perhaps it makes sense to have tests corresponding to all the examples > in Documentation/, perhaps not. How do people feel about this? Agreed, we don't want to say that the set of litmus tests in the kernel source tree is limited for all time to the set currently present, but rather that the justification for adding more would involve useful and educational examples of litmus-test features and techniques rather than being a full-up LKMM test suite. I would guess that there are litmus-test tricks that could usefully be added to tools/memory-model/litmus-tests. Any nomination? Perhaps handling CAS loops while maintaining finite state space? Something else? Thanx, Paul