From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8F2FC433E0 for ; Wed, 3 Mar 2021 23:02:58 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 42D8764F04 for ; Wed, 3 Mar 2021 23:02:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42D8764F04 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=G7P8EJjNByDtzMqxWoXqUeCDL2+7aNUEHgQ6b+yCL9w=; b=kmmUAOB+/iuRkst7Ni5ARTCtw Kv/xf0ntTKknK18YLlsKmbMFvf8jglMdUNKCBQW3bitS3NpkTLeQT85MiJjM5QghLPOxbfIrT22eo fIJCRtW7Dg59qcTMrnnlgRElK3g1OlifDpdZeOR6rcZNn0cx88+BKGfZZW3BkPHacRZpRx0hFh0hd /o9KsbhK3hg+ZPnYGjExzm4zoLow2UQEdE7ekL7veswwZWea06Bf6Cs4RMsoDwbYOJQK8xs6JhMua /GXmYq5RZsKJmy5ISjxZB0A2LMI6n9LckViibTh8xWIw3AW76axifhVBSJdv4EXJsNFJPVdy+wmBA z4dx9M8xA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHaS1-006qF6-B8; Wed, 03 Mar 2021 22:58:59 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHTY3-005PhD-Fx for linux-arm-kernel@lists.infradead.org; Wed, 03 Mar 2021 15:36:29 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E5F6764EC3; Wed, 3 Mar 2021 15:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1614785785; bh=TjGRLHTVQrYcJtDzwMx3Ml5W/yC17bs2tGUhafsU65Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WfoJZiixkbpSLBdnmBY3TWnwG10nTI59EaFqdLmIm8R71l0oqMD5a+Mki2uheMZgp vzNDIBqJhbvsnwoMI10WoJ5R59ILk5J4rse7wmUh/UvN8yyGHkYyepW+YZNhDuxfdb neAcLATO+eWfI3gFUDKl0A/VYMcmuY7Rk39cfpQQVydz2ZvM0p08NbYE/ssU5Mc/jh 2BZ6AaCRuK4ydAUq63kgUriFeyRfAtqctbQ37A+q60U1TZ1rR2+wrYtPamxjBk6qpo nLT+JfnnkN8FUkbEiJqc+obzFUNFnsIlZNlaMQ49rtTly1xZySWpusf+Y1ED/l+TRW +yMZe307OhvKQ== Date: Wed, 3 Mar 2021 15:36:19 +0000 From: Will Deacon To: Hector Martin Cc: Linux ARM , Marc Zyngier , Mark Rutland , Peter Zijlstra , Boqun Feng , Catalin Marinas Subject: Re: LSE atomic op ordering is weaker than intended? Message-ID: <20210303153619.GA19247@willie-the-truck> References: <90ea3e27-b2ef-41ac-75c7-5f0686603b2a@marcan.st> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <90ea3e27-b2ef-41ac-75c7-5f0686603b2a@marcan.st> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Hector, On Wed, Mar 03, 2021 at 10:05:19PM +0900, Hector Martin wrote: > While yak shaving the AIC driver ordering minutiae, I came across this. > > atomic_t.txt describes "fully ordered" atomic ops as follows: > > > Fully ordered primitives are ordered against everything prior and > > everything subsequent. Therefore a fully ordered primitive is like > > having an smp_mb() before and an smp_mb() after the primitive. > > And among those ops are the atomic_fetch_* ops. These are implemented as > e.g. LDSETAL, with acquire-release semantics. > > However, the *AL LSE ops have acquire semantics *for the read* and release > semantics *for the write*. As independent components of the same atomic op, > I cannot find anything in the ARM ARM that would imply ordering between the > Load-Acquire and *prior* memory operations, nor ordering between the > Store-Release and *subsequent* memory operations. > > So it would seem these ops are not in fact fully ordered, but rather, only > order the read component against prior ops, and the write component against > subsequent ops. > > Put another way: the current implementation means that unqualified ops are > equal to _acquire + _release semantics as they are described in > atomic_t.txt, but that is weaker than "fully ordered". > > Throwing this litmus test at herd7 seems to confirm this theory: > > AArch64 lse-atomic-al-ops-are-not-fully-ordered > "" > { > 0:X1=x; 0:X3=y; > 1:X1=x; 1:X3=y; > } > P0 | P1 ; > MOV X0, #1 | MOV X0, #1 ; > LDSETAL X0, X2, [X1] | LDSETAL X0, X2, [X3]; > LDR X4, [X3] | LDR X4, [X1] ; > exists (0:X4=0 /\ 1:X4=0) > > The positive result goes away adding a DMB ISH (i.e. smp_mb()) after the > atomic ops, which contradicts the atomic_t.txt claim. > > Did I miss something, or is this in fact an issue? Both. The -AL atomics are actually special-cased in the "barrier-ordered-before" relation in the Arm ARM: [RW1 is barrier-ordered-before if] * RW1 appears in program order before an atomic instruction with both Acquire and Release semantics that appears in program order before RW2. However, that isn't sufficient to order prior accesses with the "load part" of the RmW and later accesses with the "store part" of the RmW, as you have observed in your test. I'm aware of some pending proposals in this area of the architecture, so I'm reluctant to make any changes until that's bottomed-out, but I'll make a note to chase that up. > (And while I'm talking to the right people: this issue aside, do atomic ops > on Normal memory create ordering with Device memory ops, or are there no > guarantees there due to the fact that Normal memory is mapped > inner-shareable and the ordering guarantees thus do not extend to > outer-shareable Device accesses? My currenty understanding is the latter, > but I find the ARM ARM wording hard to conclusively grok here.) Outer-shareable is a superset of inner-shareable, but I think this would be easier with a specific example. I'll go and look at the AIC patch, since this is all a lot easier to talk about in the context of some real code. Which is the latest version I should look at? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel