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
| ||
|
Date: Wed, 4 Jun 2008 12:00:10 +1000 From: Nick Piggin <nickpiggin@...oo.com.au> To: Trent Piepho <tpiepho@...escale.com> Cc: Matthew Wilcox <matthew@....cx>, Linus Torvalds <torvalds@...ux-foundation.org>, Russell King <rmk+lkml@....linux.org.uk>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, David Miller <davem@...emloft.net>, linux-arch@...r.kernel.org, scottwood@...escale.com, linuxppc-dev@...abs.org, alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org Subject: Re: MMIO and gcc re-ordering issue On Wednesday 04 June 2008 07:58, Trent Piepho wrote: > On Tue, 3 Jun 2008, Matthew Wilcox wrote: > > On Tue, Jun 03, 2008 at 12:57:56PM -0700, Trent Piepho wrote: > >> On Tue, 3 Jun 2008, Matthew Wilcox wrote: > >>> On Tue, Jun 03, 2008 at 11:47:00AM -0700, Trent Piepho wrote: > >>>> On Tue, 3 Jun 2008, Linus Torvalds wrote: > >>>>> On Tue, 3 Jun 2008, Nick Piggin wrote: > >>>>>> Linus: on x86, memory operations to wc and wc+ memory are not > >>>>>> ordered with one another, or operations to other memory types (ie. > >>>>>> load/load and store/store reordering is allowed). Also, as you know, > >>>>>> store/load reordering is explicitly allowed as well, which covers > >>>>>> all memory types. So perhaps it is not quite true to say > >>>>>> readl/writel is strongly ordered by default even on x86. You would > >>>>>> have to put in some mfence instructions in them to make it so. > >>>> > >>>> So on x86, these could be re-ordered? > >>>> > >>>> writel(START_OPERATION, CONTROL_REGISTER); > >>>> status = readl(STATUS_REGISTER); > >>> > >>> You wouldn't ask for write-combining memory mapping for control or > >>> status registers. > >> > >> But Nick said, "store/load reordering is explicitly allowed as well, > >> which covers *all* memory types." > > > > Then Nick is confused. PCI only defines one way to flush posted writes > > to a device -- doing a read from it. There's no way that reads can > > be allowed to pass writes (unless you've asked for it, like with write > > combining). > > But that requirement is for the PCI bridge, isn't it? It doesn't matter if > the bridge will flush all posted writes before allowing a read if the CPU > decides to give the bridge the read before the write. A powerpc CPU will > certainly do this if you don't take any steps like telling it the memory is > uncachable and guarded. I didn't think it was allowed on x86 (except with > WC), but Nick seemed to say it was. Ah sorry, not UC, I was confused. UC I think actually is strongly ordered WRT other UC and also cacheable operations. WC is weakly ordered, anything goes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists