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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 AD163C433E0 for ; Thu, 2 Jul 2020 15:07:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 5CB82206B7 for ; Thu, 2 Jul 2020 15:07:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HIw5kTy9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="PcEiNPxu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CB82206B7 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=tLWiMAeAOAIdfuA9JfHe+o64iR0XiTPs6OckRq/VGmQ=; b=HIw5kTy92fzcIXxXWWJa9u0ti Nyf4RKgTuzJ5uN4kYPztfVP2tg8419NYLoSLI3srE6cRrD744iOarb89lTC5qtVJJc2zLws18ZW+y xG7UK0uowOxqaApVhOe2KI8Och4HP0tsFKu6bhR9c8iltCHQNB2PzDeB2JHapmxA518IlHLTRUqZi PPkidHuMT+QlmyxfYkLQrX0Nh0ihDg3czqNXuGQ8j20xnH/Lr8Efets2dC8xPGN/9M8UILV/5XZeT 4t5H4CSADtn6k8uMijET6rabLHaPYAvssDZ3MzGN55FidSk3YLcEl4dOrqB3Uf8FWeL0dD1p2aqIW kJXNDoclA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr0lx-00078H-61; Thu, 02 Jul 2020 15:05:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jr0cp-000289-IT for linux-arm-kernel@lists.infradead.org; Thu, 02 Jul 2020 14:55:58 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (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 1105F2075D; Thu, 2 Jul 2020 14:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593701741; bh=nbXe6nJCNrMku6QIpQkPDTVx3nVSr/HZ3tO6LrfZY8Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PcEiNPxuhlEyLh2HMXcrpBV1EC5XLsFjtMKSlRSdePnrAVWjczQYEysgptdOEIbNb QjfUU6jDXo4nj7OwF7ffPzJvSQ1L4KMCNuYjhVu7foez1h5841jqZdO+/Wfss7iN0Y tyFLYFMHbSNeYbjpimnr2GDt6pYflThH5++ITr0w= Date: Thu, 2 Jul 2020 15:55:33 +0100 From: Will Deacon To: Joel Fernandes Subject: Re: [PATCH 04/18] alpha: Override READ_ONCE() with barriered implementation Message-ID: <20200702145532.GB16999@willie-the-truck> References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-5-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200702_105543_821958_9A603308 X-CRM114-Status: GOOD ( 26.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, "Joel Fernandes \(Google\)" , Arnd Bergmann , Alan Stern , Sami Tolvanen , Matt Turner , "Cc: Android Kernel" , Marco Elver , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , Ivan Kokshaysky , "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)" , Richard Henderson , Nick Desaulniers , LKML , linux-alpha@vger.kernel.org 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 Joel, On Thu, Jul 02, 2020 at 10:43:55AM -0400, Joel Fernandes wrote: > On Tue, Jun 30, 2020 at 1:38 PM Will Deacon wrote: > > diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h > > index 92ec486a4f9e..2ecd068d91d1 100644 > > --- a/arch/alpha/include/asm/barrier.h > > +++ b/arch/alpha/include/asm/barrier.h > > - * For example, the following code would force ordering (the initial > > - * value of "a" is zero, "b" is one, and "p" is "&a"): > > - * > > - * > > - * CPU 0 CPU 1 > > - * > > - * b = 2; > > - * memory_barrier(); > > - * p = &b; q = p; > > - * read_barrier_depends(); > > - * d = *q; > > - * > > - * > > - * because the read of "*q" depends on the read of "p" and these > > - * two reads are separated by a read_barrier_depends(). However, > > - * the following code, with the same initial values for "a" and "b": > > - * > > Would it be Ok to keep this example in the kernel sources? I think it > serves as good documentation and highlights the issue in the Alpha > architecture well. I'd _really_ like to remove it, as I think it only serves to confuse people on a topic that is confusing enough already. Paul's perfbook [1] already has plenty of information about this, so I don't think we need to repeat that here. I could add a citation, perhaps? > > - * > > - * CPU 0 CPU 1 > > - * > > - * a = 2; > > - * memory_barrier(); > > - * b = 3; y = b; > > - * read_barrier_depends(); > > - * x = a; > > - * > > - * > > - * does not enforce ordering, since there is no data dependency between > > - * the read of "a" and the read of "b". Therefore, on some CPUs, such > > - * as Alpha, "y" could be set to 3 and "x" to 0. Use rmb() > > - * in cases like this where there are no data dependencies. > > - */ > > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > > +#define __smp_load_acquire(p) \ > > +({ \ > > + __unqual_scalar_typeof(*p) ___p1 = \ > > + (*(volatile typeof(___p1) *)(p)); \ > > + compiletime_assert_atomic_type(*p); \ > > + ___p1; \ > > +}) > > I had the same question as Mark about the need for a memory barrier > here, otherwise alpha will again break right? Looking forward to the > future fix you mentioned. Yeah, sorry about that. It went missing somehow during the rebase, it seems. > BTW, do you know any architecture where speculative execution of > address-dependent loads can cause similar misorderings? That would be > pretty insane though. In Alpha's case it is not speculation but rather > the split local cache design as the docs mention. The reason I ask > is it is pretty amusing that control-dependent loads do have such > misordering issues due to speculative branch execution and I wondered > what other games the CPUs are playing. FWIW I ran into [1] which talks > about analogy between memory dependence and control dependence. I think you're asking about value prediction, and the implications it would have on address-dependent loads where the address can itself be predicted. I'm not aware of an CPUs where that is observable architecturally. arm64 has some load instructions that do not honour address dependencies, but I believe that's mainly to enable alternative cache designs for things like non-temporal and large vector loads. Will [1] https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel