Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1610051imm; Thu, 12 Jul 2018 05:04:28 -0700 (PDT) X-Google-Smtp-Source: AAOMgpee4j94+zuFK/i0sa72RAQNmEnJPvmHhSu8wORJBksCkYEoZ2wEJGgfWzssjWBgx9JyM0nO X-Received: by 2002:a62:ccd0:: with SMTP id j77-v6mr2128130pfk.22.1531397068533; Thu, 12 Jul 2018 05:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531397068; cv=none; d=google.com; s=arc-20160816; b=H2RhAOcWx6w3BzwBHesjVvrDuP9cOHGLsKUTuGjjsN2sDLIrJEjJmrO+Wsy2e2KZVN y1N1O0kWlcbLZf+Ul0ZbhtJMtQObvUhURFDBL7VjwJJLsdbEGyv7jiLqbmt+v0C8XICZ /RQ2gTsh9xG8eSsxtv913Ov1g3SoGvCjv15MXzUQ9quNlea7bAF2AYx9xrOlmlcV1Ob/ rAlERBcvuqPjgI51nwqWB5zvTHcmSaAk3saDT7hYFNNo90lqjmnCob6Zx6oudtDp58VE km7klE5HP9fxy12m7pZq7+O7Cv7/AuamhH2MTTl/xq7pNjmRUzy3mt2d5Hhc2UNylav2 bE/Q== 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:from:date:dkim-signature:arc-authentication-results; bh=DrjMqM9DfRkdPO3b8AbZcqKJWVhEEiaN5vW1Y5jijMs=; b=kuWezlKp3sgVeBc9H6mebW+kCg8U1wSGIOHFHK9kcmVa+IEJKyHKTzk6wWBMF6i0kg gZrSevpqRm0N9crOxQzx2EnEX3nB07LmT3LyuSKXyRGgW0clOVPvYvdjarVJCA1Liss6 jc1uzbmEaWJ0KIAcL6amhtnmT1cUzXstwtAmbGci1apNFXD3pITqoisz5so8RKP8GRXR cBnuRrkFn+IzxTHJN20ESbd/aJPTic2crcIUh4+2KB1VZh7gQMB7Hp+FgfyhN26Q2W3E xC0Yak38z5L2VrPhMDhLHrG1yZGkJKBAtRBemmrdRzd7zsoO6GS4pdGsetH/xM/jE2+J I7FA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=RD67On7R; 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 b4-v6si11317962pgg.537.2018.07.12.05.04.12; Thu, 12 Jul 2018 05:04:28 -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; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=RD67On7R; 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 S1732585AbeGLMKY (ORCPT + 99 others); Thu, 12 Jul 2018 08:10:24 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:46005 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726701AbeGLMKY (ORCPT ); Thu, 12 Jul 2018 08:10:24 -0400 Received: by mail-wr1-f67.google.com with SMTP id c4-v6so8761861wrs.12 for ; Thu, 12 Jul 2018 05:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DrjMqM9DfRkdPO3b8AbZcqKJWVhEEiaN5vW1Y5jijMs=; b=RD67On7RKWDz3Pm3K08Leq+4W0QPR4923OI+J0xeWXKv22NmY8CaIzrcSi91LPT7J7 ryKP/NtE2xFgkOEqgSAEmigsGiDGI6wH2K4dqEpuWf96LaA60r/oJLEFwn5M+qMtFuPs aEEdPZaFh6dXHwOOxoEqCIEyPZ80ZVXb06Jjo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DrjMqM9DfRkdPO3b8AbZcqKJWVhEEiaN5vW1Y5jijMs=; b=Q0peGgDXpIhHVna5izIZ+0XbmurBLVRi699zBkALc5N+u9KA+jzuIrApkiZti/a9Po smhKOHQAnc8eK9+RyMFZC1UE7NdHVmXl6XyE3PmE3ra+ifBsi+O7+oCEx1yDS3WWaZED +lzZ2iZ7DkJbfF6f+D/270DU7p8kBrYOL7fGKugvYTUdXD4LaJYGLtoY1yiUqMczjJCY xA2q9lQYzCmEVd9Ex51R/eg9omuRe4Zli6nn6VuoAk7xiZkwklOsPYIcWGSeFej/Gmpg Oc1P17zO5AGE5XLwu2ePR0G0uEpSSX+9Ceep06EsH1YOUXFxRb3OOJ4AC7F0j0SctiE4 Atag== X-Gm-Message-State: AOUpUlEWujuIj+5FYpQfkquHBNFvihz23aB7ym/0RDa/mNCPXMCoIQD6 4OGZYAdOcR/+Sh7HofckpRrncw== X-Received: by 2002:adf:ae51:: with SMTP id u17-v6mr1465690wrd.201.1531396867368; Thu, 12 Jul 2018 05:01:07 -0700 (PDT) Received: from andrea (85.100.broadband17.iol.cz. [109.80.100.85]) by smtp.gmail.com with ESMTPSA id k13-v6sm17022485wrr.14.2018.07.12.05.01.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 05:01:06 -0700 (PDT) Date: Thu, 12 Jul 2018 14:01:00 +0200 From: Andrea Parri To: Peter Zijlstra Cc: Will Deacon , Alan Stern , "Paul E. McKenney" , LKMM Maintainers -- Akira Yokosawa , Boqun Feng , Daniel Lustig , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Kernel development list Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Message-ID: <20180712120100.GA7404@andrea> References: <20180710093821.GA5414@andrea> <20180711094310.GA13963@arm.com> <20180711123421.GA9673@andrea> <20180712074040.GA4920@worktop.programming.kicks-ass.net> <20180712115249.GA6201@andrea> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180712115249.GA6201@andrea> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 12, 2018 at 01:52:49PM +0200, Andrea Parri wrote: > On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote: > > > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the > > > simplest solution would be to get rid of rfi-rel-acq and unlock-rf-lock-po > > > (or its analogous in v3) all together: > > > > > > > > > Among other things, this would immediately: > > > > > > 1) Enable RISC-V to use their .aq/.rl annotations _without_ having to > > > "worry" about tso or release/acquire fences; IOW, this will permit > > > a partial revert of: > > > > > > 0123f4d76ca6 ("riscv/spinlock: Strengthen implementations with fences") > > > 5ce6c1f3535f ("riscv/atomic: Strengthen implementations with fences") > > > > But I feel this goes in the wrong direction. This weakens the effective > > memory model, where I feel we should strengthen it. > > > > Currently PowerPC is the weakest here, and the above RISC-V changes > > (reverts) would make RISC-V weaker still. > > > > Any any effective weakening makes me very uncomfortable -- who knows > > what will come apart this time. This memory ordering stuff causes > > horrible subtle bugs at best. > > Indeed, what I was suggesting above is a weaking of the current model > (and I agree: I wouldn't say that bugs in this context are nice ;-). > > These changes would affect a specific area: (IMO,) the examples we've > been considering here aren't for the faint-hearted ;-) and as Daniel > already suggested, everything would again be "nice and neat", if this > was all about locking/if every thread used lock-synchronization. > > > > > > > 2) Resolve the above mentioned controversy (the inconsistency between > > > - locking operations and atomic RMWs on one side, and their actual > > > implementation in generic code on the other), thus enabling the use > > > of LKMM _and_ its tools for the analysis/reviewing of the latter. > > > > This is a good point; so lets see if there is something we can do to > > strengthen the model so it all works again. > > > > And I think if we raise atomic*_acquire() to require TSO (but ideally > > raise it to RCsc) we're there. > > > > The TSO archs have RCpc load-acquire and store-release, but fully > > ordered atomics. Most of the other archs have smp_mb() everything, with > > the exception of PPC, ARM64 and now RISC-V. > > > > PPC has the RCpc TSO fence LWSYNC, ARM64 has the RCsc > > load-acquire/store-release. And RISC-V has a gazillion of options IIRC. > > > > > > So ideally atomic*_acquire() + smp_store_release() will be RCsc, and is > > with the notable exception of PPC, and ideally RISC-V would be RCsc > > here. But at the very least it should not be weaker than PPC. > > > > By increasing atomic*_acquire() to TSO we also immediately get the > > proposed: > > > > P0() > > { > > WRITE_ONCE(X, 1); > > spin_unlock(&s); > > spin_lock(&s); > > WRITE_ONCE(Y, 1); > > } > > > > P1() > > { > > r1 = READ_ONCE(Y); > > smp_rmb(); > > r2 = READ_ONCE(X); > > } > > > > behaviour under discussion; because the spin_lock() will imply the TSO > > ordering. > > You mean: "when paired with a po-earlier release to the same memory > location", right? I am afraid that neither arm64 nor riscv current > implementations would ensure "(r1 == 1 && r2 == 0) forbidden" if we > removed the po-earlier spin_unlock()... > > AFAICT, the current implementation would work with that release: as > you remarked above, arm64 release->acquire is SC; riscv has an rw,w > fence in its spin_unlock() (hence an w,w fence between the stores), > or it could have a .tso fence ... > > But again, these are stuble patterns, and my guess is that several/ > most kernel developers really won't care about such guarantees (and > if some will do, they'll have the tools to figure out what they can > actually rely on ...) > > OTOH (as I pointed out earlier) the strengthening we're configuring > will prevent some arch. (riscv being just the example of today!) to > go "full RCsc", and this will inevitably "complicate" both the LKMM "full RCpc" Andrea > and the reviewing process of related changes (atomics, locking, ...; > c.f., this debate), apparently, just because you ;-) want to "care" > about these guarantees. > > Not yet convinced ... :/ > > Andrea > > > > > > And note that this retains regular RCpc ACQUIRE for smp_load_acquire() > > and associated primitives -- as they have had since their introduction > > not too long ago.