linux-kernel - Re: [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Feb 2019 11:36:09 +0000
From:   Will Deacon <will.deacon@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrea Parri <andrea.parri@...rulasolutions.com>,
        Daniel Lustig <dlustig@...dia.com>,
        David Howells <dhowells@...hat.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O
 BARRIER EFFECTS" section

On Tue, Feb 19, 2019 at 12:31:50PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 19, 2019 at 11:27 AM Thomas Petazzoni
> <thomas.petazzoni@...tlin.com> wrote:
> > On Mon, 18 Feb 2019 21:37:25 +0100
> > Arnd Bergmann <arnd@...db.de> wrote:
> >
> > > Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> > > see 6a02734d420f ("ARM: mvebu: map PCI I/O regions strongly ordered")
> > > and prior commits.
> >
> > Yes, some Marvell Armada 32-bit platforms have an errata that require
> > the PCI MEM and PCI I/O regions to be mapped strongly ordered.
> >
> > BTW, this requirement prevents us from using the pci_remap_iospace()
> > API from drivers/pci, because it assumes page attributes of
> > pgprot_device(PAGE_KERNEL). That's why we're still using the
> > ARM-specific pci_ioremap_io() function.
> 
> Ok.
> 
> > > > I would still prefer to document the weaker semantics as the portable
> > > > interface, unless there are portable drivers relying on this today (which
> > > > would imply that it's widely supported by other architectures).
> > >
> > > I don't know of any portable driver that actually relies on it, but
> > > that's mainly because there are very few portable drivers that
> > > use inb()/outb() in the first place. How many of those require
> > > the non-posted behavior I don't know
> > >
> > > Adding Thomas, Gregory and Russell to Cc, as they were involved
> > > in the discussion that led to the 32-bit change, maybe they are
> > > aware of a specific example.
> >
> > I'm just arriving in the middle of this thread, and I'm not sure to
> > understand what is the question. If the question is whether PCI I/O is
> > really used in practice, then I've never seen it be used with Marvell
> > platforms (but I'm also not aware of all PCIe devices people are
> > using). I personally have a hacked-up version of the e1000e driver
> > that intentionally does some PCI I/O accesses, that I use as a way to
> > validate that PCI I/O support is minimally working, but that's it.
> 
> The main question is whether we know of a portable (not specific
> to a single architecture) driver for PCIe (or PCI, but probably not ISA)
> that uses outb/outw/outl in a way that relies on the on-posted
> behavior of those, compared to posted writeb/writew/writel that are
> only required to complete before another I/O operation on the same
> device but whose completion is not ordered with regard to the rest of
> the system.
> 
> I think an example of this would be a driver using outb() to disable
> an interrupt, and then relying on the the interrupt no longer happening
> after the outb().

Isn't that racy already? i.e. the interrupt could fire just before you
disabled it, but not get delivered by the irq controller until after you'd
disabled it at the device?

Will