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=-10.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 5BEB5C4360F for ; Thu, 4 Apr 2019 16:40:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 28B66206DF for ; Thu, 4 Apr 2019 16:40:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729513AbfDDQka (ORCPT ); Thu, 4 Apr 2019 12:40:30 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35420 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727152AbfDDQk3 (ORCPT ); Thu, 4 Apr 2019 12:40:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A9F88169E; Thu, 4 Apr 2019 09:40:28 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4B7223F557; Thu, 4 Apr 2019 09:40:25 -0700 (PDT) Date: Thu, 4 Apr 2019 17:40:22 +0100 From: Will Deacon To: Akira Yokosawa Cc: "Paul E. McKenney" , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, stern@rowland.harvard.edu, andrea.parri@amarulasolutions.com, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, Benjamin Herrenschmidt , Michael Ellerman , Arnd Bergmann , Palmer Dabbelt , Daniel Lustig , Linus Torvalds , "Maciej W. Rozycki" , Mikulas Patocka Subject: Re: [PATCH tip/core/rcu 04/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section Message-ID: <20190404164022.GB28932@fuggles.cambridge.arm.com> References: <20190326234114.GA23843@linux.ibm.com> <20190326234133.24962-4-paulmck@linux.ibm.com> <20190402130346.GA14559@fuggles.cambridge.arm.com> <7c0b1afc-9308-e060-d1cc-7389a2330e97@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c0b1afc-9308-e060-d1cc-7389a2330e97@gmail.com> User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Akira, On Fri, Apr 05, 2019 at 12:58:36AM +0900, Akira Yokosawa wrote: > On Tue, 2 Apr 2019 14:03:46 +0100, Will Deacon wrote: > > On Tue, Mar 26, 2019 at 04:41:16PM -0700, Paul E. McKenney wrote: > >> From: Will Deacon > >> > >> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague, > >> x86-centric, out-of-date, incomplete and demonstrably incorrect in places. > >> This is largely because I/O ordering is a horrible can of worms, but also > >> because the document has stagnated as our understanding has evolved. > >> > >> Attempt to address some of that, by rewriting the section based on > >> recent(-ish) discussions with Arnd, BenH and others. Maybe one day we'll > >> find a way to formalise this stuff, but for now let's at least try to > >> make the English easier to understand. > >> > >> Cc: "Paul E. McKenney" > >> Cc: Benjamin Herrenschmidt > >> Cc: Michael Ellerman > >> Cc: Arnd Bergmann > >> Cc: Peter Zijlstra > >> Cc: Andrea Parri > >> Cc: Palmer Dabbelt > >> Cc: Daniel Lustig > >> Cc: David Howells > >> Cc: Alan Stern > >> Cc: Linus Torvalds > >> Cc: "Maciej W. Rozycki" > >> Cc: Mikulas Patocka > >> Signed-off-by: Will Deacon > >> Signed-off-by: Paul E. McKenney > >> --- > >> Documentation/memory-barriers.txt | 115 ++++++++++++++++++------------ > >> 1 file changed, 70 insertions(+), 45 deletions(-) > > > > If somebody could provide an Ack on this patch, I'd really appreciate it, > > please. Whilst the portable ordering guarantees that I've documented are > > fairly conservative, I do think that this change is a big improvement and > > gives you what you need if you're writing a portable device driver for a new > > piece of hardware. I'm tackling the removal of MMIOWB as a separate series. > > > > I think Paul now requires an Ack before he'll send a patch to mainline, > > hence the grovelling. > > I'm afraid I'm not that qualified to provide an Ack to this patch, > but please find a nit fix below. Oh well, thanks for having a look anyway! > >> + (*) insX(), outsX(): > >> + > >> + As above, the insX() and outX() accessors provide the same ordering > outsX() Thanks; I'll fix that. > >> + guarantees as readsX() and writesX() respectively when accessing a mapping > >> + with the default I/O attributes. > >> > >> (*) ioreadX(), iowriteX() > >> > >> These will perform appropriately for the type of access they're actually > >> doing, be it inX()/outX() or readX()/writeX(). > >> > >> +All of these accessors assume that the underlying peripheral is little-endian, > >> +and will therefore perform byte-swapping operations on big-endian architectures. > >> + > >> +Composing I/O ordering barriers with SMP ordering barriers and LOCK/UNLOCK > >> +operations is a dangerous sport which may require the use of mmiowb(). See the > >> +subsection "Acquires vs I/O accesses" for more information. > >> > >> ======================================== > >> ASSUMED MINIMUM EXECUTION ORDERING MODEL > >> -- > >> 2.17.1 > >> > > JFYI, there is another document Documentation/driver-api/device-io.rst, > which is somewhat related to this update. It looks like this one also needs > some update, as Jon commented in transforming to .rst format in commit > 8a8a602fdb83 ("docs: Convert the deviceio template to RST"): > > Like the rest of our documentation, this one could use some work. There's > no mention of ioremap() and friends, no mention of io_read*() and friends. > But we have nice documentation for all those folks writing new drivers that > do port I/O :). > > > This commit was merged in v4.11 cycle. And there has been no update whatsoever > since. mmiowb() is lightly mentioned therein. IMHO, just updating > memory-barriers.txt would widen the gap of information. > > Thoughts? I have a subsequent patch which kills mmiowb() entirely: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/mmiowb&id=3c1a2050c08fb8193777b60b49e60320254a156c and that one does hit device-io.rst. Will