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: <aday7r4a3d7.fsf@cisco.com>
Date:	Wed, 25 Oct 2006 07:15:16 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	David Miller <davem@...emloft.net>
Cc:	matthew@....cx, jeff@...zik.org,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-ia64@...r.kernel.org,
	linux-kernel@...r.kernel.org, openib-general@...nib.org,
	johnip@....com
Subject: Re: Ordering between PCI config space writes and MMIO reads?

 > One thing is that we definitely don't want to fix this by,
 > for example, reading back the PCI_COMMAND register or something
 > like that.  That causes two problems:
 > 
 > 1) Some PCI config writes shut the device down and make it
 >    no respond to some kinds of PCI config transactions.
 >    One example is putting the device into D3 or similar
 >    power state, another is performing a device reset.

Hmm... it seems there is no other guaranteed way to make sure a config
write has really completed except doing a config read.  And only the
driver knows what the config access it's doing means.  So the
conclusion we seem to be forced into is that drivers need to include
these reads in the cases where they are needed.

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