From patchwork Wed Apr 4 15:52:20 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Sinan Kaya X-Patchwork-Id: 10322815 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 434096053F for ; Wed, 4 Apr 2018 15:52:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 33DFC284B9 for ; Wed, 4 Apr 2018 15:52:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 283AE28517; Wed, 4 Apr 2018 15:52:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 8BE11284B9 for ; Wed, 4 Apr 2018 15:52:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vRp1g/jCAj2tW/b1ROfcYJxHyuJRCVfPMiIm6ZkogRA=; b=UDtQPLm1s8fLl+ qhmkgNyuyWgLWrgM7fPkkyL60HIHjlEkmwLJRScNceimdOkltCcifS5Vk5krmiAOCOiIUFbiBAzel p8lf9SYIfcoilgvFV1wcWVdJh2U4nwaVSVXtDPfqZRJfUUisyl9HSOSbfv+bPy9vtVLHIuFW8w6XP wcqx7CQHvgxnRgkg6u2fZEX+uoIzS8eITrlnoXj0SZNDX8OEjeiLwqh8EgQuYfx2B4txjnXDyAtNX T7MG0VFwyP+W8ATiIkS4TA5HL0XV5hKD9e8ZtRLY84TknWssuacqka1NHE0iWWe7YMxWHZuEyIvjI ygnrQKbfudcJxovF7cBw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1f3kiE-0002fQ-MJ; Wed, 04 Apr 2018 15:52:38 +0000 Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1f3ki9-0002ZB-T8 for linux-arm-kernel@lists.infradead.org; Wed, 04 Apr 2018 15:52:36 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id A6E6860817; Wed, 4 Apr 2018 15:52:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522857142; bh=NMWU3O0G152eA3E4vzdqpH2oiVUOusDA372SGYfMpvk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=A+4SfT9tqmh5FAo9MDaZHGAi4sls4qChi0lHOQkZIR824D/6KLwjSnMvS5hGVfOa0 4MiFKFF2BshAEyU01cLBQwglBpQ1dCk6ELQZ7adTZsSZHEIwEb7fcnRgL8tEhA8qA8 E4Cp9AmAxwraeGt8PNpGbwIocNO6yXVtKY9CUViY= Received: from [10.235.228.150] (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5321B607A2; Wed, 4 Apr 2018 15:52:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522857142; bh=NMWU3O0G152eA3E4vzdqpH2oiVUOusDA372SGYfMpvk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=A+4SfT9tqmh5FAo9MDaZHGAi4sls4qChi0lHOQkZIR824D/6KLwjSnMvS5hGVfOa0 4MiFKFF2BshAEyU01cLBQwglBpQ1dCk6ELQZ7adTZsSZHEIwEb7fcnRgL8tEhA8qA8 E4Cp9AmAxwraeGt8PNpGbwIocNO6yXVtKY9CUViY= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5321B607A2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v2 2/2] io: prevent compiler reordering on the default readX() implementation To: Palmer Dabbelt , Arnd Bergmann References: From: Sinan Kaya Message-ID: <691b903c-e97d-0a25-28c5-690318bb215a@codeaurora.org> Date: Wed, 4 Apr 2018 11:52:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180404_085234_046228_783980E0 X-CRM114-Status: GOOD ( 23.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, linux-arch@vger.kernel.org, sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, timur@codeaurora.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 4/3/2018 6:29 PM, Palmer Dabbelt wrote: > On Tue, 03 Apr 2018 05:56:18 PDT (-0700), Arnd Bergmann wrote: >> On Tue, Apr 3, 2018 at 2:44 PM, Sinan Kaya wrote: >>> On 4/3/2018 7:13 AM, Arnd Bergmann wrote: >>>> On Tue, Apr 3, 2018 at 12:49 PM, Mark Rutland wrote: >>>>> Hi, >>>>> >>>>> On Fri, Mar 30, 2018 at 11:58:13AM -0400, Sinan Kaya wrote: >>>>>> The default implementation of mapping readX() to __raw_readX() is wrong. >>>>>> readX() has stronger ordering semantics. Compiler is allowed to reorder >>>>>> __raw_readX(). >>>>> >>>>> Could you please specify what the compiler is potentially reordering >>>>> __raw_readX() against, and why this would be wrong? >>>>> >>>>> e.g. do we care about prior normal memory accesses, subsequent normal >>>>> memory accesses, and/or other IO accesses? >>>>> >>>>> I assume that the asm-generic __raw_{read,write}X() implementations are >>>>> all ordered w.r.t. each other (at least for a specific device). >>>> >>>> I think that is correct: the compiler won't reorder those because of the >>>> 'volatile' pointer dereference, but it can reorder access to a normal >>>> pointer against a __raw_readl()/__raw_writel(), which breaks the scenario >>>> of using writel to trigger a DMA, or using a readl to see if a DMA has >>>> completed. >>> >>> Yes, we are worried about memory update vs. IO update ordering here. >>> That was the reason why barrier() was introduced in this patch. I'll try to >>> clarify that better in the commit text. >>> >>>> >>>> The question is whether we should use a stronger barrier such >>>> as rmb() amd wmb() here rather than a simple compiler barrier. >>>> >>>> I would assume that on complex architectures with write buffers and >>>> out-of-order prefetching, those are required, while on architectures >>>> without those features, the barriers are cheap. >>> >>> That's my reasoning too. I'm trying to follow the x86 example here where there >>> is a compiler barrier in writeX() and readX() family of functions. >> >> I think x86 is the special case here because it implicitly guarantees >> the strict ordering in the hardware, as long as the compiler gets it >> right. For the asm-generic version, it may be better to play safe and >> do the safest version, requiring architectures to override that barrier >> if they want to be faster. >> >> We could use the same macros that riscv has, using __io_br(), >> __io_ar(), __io_bw() and __io_aw() for before/after read/write. > > FWIW, when I wrote this I wasn't sure what the RISC-V memory model was going to be so I just picked something generic.  In other words, it's already a generic interface, just one that we're the only users of :). > Are we looking for something like this? diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index e8c2078..693a82f 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -101,6 +101,16 @@ static inline void __raw_writeq(u64 value, volatile void __iomem *addr) #endif #endif /* CONFIG_64BIT */ +#ifndef __io_br() +#define __io_br() do {} while (0) +#endif + +#ifdef rmb +#define __io_ar() rmb(); +#else +#define __io_ar() barrier(); +#endif + /* * {read,write}{b,w,l,q}() access little endian memory and return result in * native endianness. @@ -108,35 +118,46 @@ static inline void __raw_writeq(u64 value, volatile void __iomem *addr) #ifndef readb #define readb readb -static inline u8 readb(const volatile void __iomem *addr) -{ - return __raw_readb(addr); -} +#define readb(c) \ + ({ u8 __v; \ + __io_br(); \ + __v = __raw_readb(c); \ + __io_ar(); \ + __v; }) #endif #ifndef readw #define readw readw -static inline u16 readw(const volatile void __iomem *addr) -{ - return __le16_to_cpu(__raw_readw(addr)); -} +#define readw(c) \ + ({ u16 __v; \ + \ + __io_br(); \ + __v = __le16_to_cpu(__raw_readw(c)); \ + __io_ar(); \ + __v; }) #endif #ifndef readl #define readl readl -static inline u32 readl(const volatile void __iomem *addr) -{ - return __le32_to_cpu(__raw_readl(addr)); -} +#define readl(c) \ + ({ u32 __v; \ + \ + __io_br(); \ + __v = __le32_to_cpu(__raw_readl(c)); \ + __io_ar(); \ + __v; }) #endif #ifdef CONFIG_64BIT #ifndef readq #define readq readq -static inline u64 readq(const volatile void __iomem *addr) -{ - return __le64_to_cpu(__raw_readq(addr)); -} +#define readq(c) \ + ({ u64 __v; \ + \ + __io_br(); \ + __v = __le64_to_cpu(__raw_readq(c)); \ + __io_ar(); \ + __v; }) #endif #endif /* CONFIG_64BIT */