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-next>] [day] [month] [year] [list]
Date:	Wed, 20 Sep 2006 12:41:05 -0700
From:	Bill Waddington <william.waddington@...zmo.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Flushing writes to PCI devices

On Wed, 20 Sep 2006 19:10:55 UTC, in fa.linux.kernel you wrote:

>
>On Wed, 20 Sep 2006, Alan Stern wrote:
>
>> I've heard that to insure proper synchronization it's necessary to flush
>> MMIO writes (writel, writew, writeb) to PCI devices by reading from the
>> same area.  Is this equally true for I/O-space writes (inl, inw, inb)?
>> What about configuration space writes (pci_write_config_dword etc.)?
>>
>> Alan Stern
>
>Writes to I/O space are not queued through a FIFO so there is
>no need to flush the FIFO. Configuration space uses special
>configuration cycles which are handshakes with the devices. They
>cannot be queued, therefore don't need to be flushed either.
>
>Flushing PCI space writes shouldn't be done until you want
>whatever you've been planning to happen __now__. Otherwise
>the advantages of queued writes go away. In other words, one
>should NOT attach a read to every PCI space write! Typically
>use of the flushing read might be in the case of setting up
>hardware for a DMA transfer. You write all the data, source
>address, destination address, byte-count, DMA type, etc., then
>after the last instruction, the one should should start the DMA,
>you issue a read.

Are there ever any issues with out-of-order writes from the posting
buffer on supported architectures?  I can (barely) imagine a device
that has the register with the start bit lower in the register address
space than the count/address registers.  Out-of-order writes from
the cache/non-fifo/posting buffer (maybe to assemble a burst) could
make the occasional mess.

Just wondering,
Bill
-- 
William D Waddington
william.waddington@...zmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ