linux-kernel - Re: Ordering between PCI config space writes and MMIO reads?

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]

Message-ID: <20061031204717.GG26964@parisc-linux.org>
Date:	Tue, 31 Oct 2006 13:47:17 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	"Richard B. Johnson" <jmodem@...minableFirebug.com>
Cc:	"Michael S. Tsirkin" <mst@...lanox.co.il>,
	Roland Dreier <rdreier@...co.com>,
	linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
	jeff@...zik.org, openib-general@...nib.org,
	linux-pci@...ey.karlin.mff.cuni.cz,
	David Miller <davem@...emloft.net>
Subject: Re: Ordering between PCI config space writes and MMIO reads?

On Tue, Oct 31, 2006 at 03:34:47PM -0500, Richard B. Johnson wrote:
> If you write to the PCI bus and then you read the result, the read 
> __might__ be the
> read that flushes any posted writes rather than the read of device 

Config space writes aren't posted, they're delayed.  So, for example,
you can do the config write on the primary bus, then it hits a bridge on
its way to the destination device.  The bridge is entitled (obviously,
it's unlikely to) drop it, and then the config read can pass by the
config write.

I'm beginning to think Michael Tsirkin has the only solution to this
-- architectures need to check that their hardware blocks until the
config write completion has occurred (and if not, simulate that it has
in software).

-
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/