Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2923198imm; Tue, 4 Sep 2018 12:11:09 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda0moqTCPRLQ6EAVpz85wwVuTrWJR8qCBADgMRmD/TXVM51GYaKLhddOuFCigDLByGw7DhF X-Received: by 2002:a17:902:5381:: with SMTP id c1-v6mr8569556pli.296.1536088269842; Tue, 04 Sep 2018 12:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536088269; cv=none; d=google.com; s=arc-20160816; b=h77BNxvPiPCydDBRRTUlRHG+GewE1JD4TsGaSbGErhHbKRiuL4ljqFiP2mc3Xb9bbY 8OPTpoCj7TR6TL+JR07ck/klv3FPSZrLoLWW1iSDjvfrcPBtEsadpXVM0h/CqMP5QAtw ZDlfpW6r5S4OlUKdKX4SEHjNV3MxLMazy35r9A3K1kHVP52h6uLUsuTphUsuqfUCDrTl ro0ONGvPKwo/P5AAeFYuihhaZ1d8angnOIbBpYetooMczGRe5f50yCbyWJoWsc/kvctD GNwaSvtxbIdQtWzgO2B9NaYrmliBBmeINmH4QCcbc3mEBkLlP1e0qZVBSR8BDFMVQPrm bHsA== 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:arc-authentication-results; bh=btEY9cb7BAA66zqN5/hEgoycsIq19sKNJDAkhxE/kzQ=; b=NoqMOPt8lhh9egU7Rgk2a+S+JO7/IIHdIQp6qVWZhWKYucf+kUu1mMnQOynMmUxfyL AVLkhNvKjFa9KMnCm2BpLy5VsNXPOciu9qoGRz3gMnGbfP2q6Xwxh5WMyXI22UG1/2Xm vI2s0rzuF38urcbZRskJtqhdJB8chYPT+v6UEqruadJ3wyLsZoq+1/lIA7nJXPlDQnt8 DxJStNjc1AMK8Usq22qFtVanRM+gC3gs4nQHA97gc8ufotEcPsX7E+jl8j01iy8+Uzq8 dLwpsKQxChYQD0VPgBDaQUxFqRv9Aciz8ejxpMSk0h5Bfyg8YN2ZqNCptCls4lvzODV5 1iCw== 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 q9-v6si22445559pgj.134.2018.09.04.12.10.54; Tue, 04 Sep 2018 12:11:09 -0700 (PDT) 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 S1727952AbeIDXgS (ORCPT + 99 others); Tue, 4 Sep 2018 19:36:18 -0400 Received: from netrider.rowland.org ([192.131.102.5]:49453 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727782AbeIDXgS (ORCPT ); Tue, 4 Sep 2018 19:36:18 -0400 Received: (qmail 19288 invoked by uid 500); 4 Sep 2018 15:09:49 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Sep 2018 15:09:49 -0400 Date: Tue, 4 Sep 2018 15:09:49 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Andrea Parri cc: Will Deacon , "Paul E. McKenney" , , , , , , , , , , Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire In-Reply-To: <20180904081144.GA4137@andrea> 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 Tue, 4 Sep 2018, Andrea Parri wrote: > Heh, your confusion might be the reflection of mine... ;-) That was > indeed a long and not conclusive discussion (meaning there're pending > issues); and I cannot claim to find "arguments" such as: > > "More than one kernel developer has expressed the opinion that > the LKMM should enforce ordering of writes by locking." > > particularly helpful (I do tend to be convinced by arguments rather > than by opinions). In fact, you can take the following as my only > current "constructive argument" against the patch [1,2]: > > THE COMMIT MESSAGE IS RIDICULOUS; PLEASE EXPAND ON IT, AND DO > SO BY LEVERAGING BOTH PROS AND CONS OF THE APPLIED CHANGES Do you have any concrete suggestions (i.e., some actual text) for improvements to the patch description? Earlier in your message you mentioned that Will's comment: LKMM offers stronger guarantees that can portably be relied upon in the codebase. would make a good addition. Suitably edited, it could be added to the description. I can think of a few other things myself, but I'd like to hear your thoughts. Anything else? Alan