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] [day] [month] [year] [list]
Date:	Mon, 22 Mar 2010 18:14:15 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Memory-mapped I/O barriers, state of affairs?

On 03/22/2010 04:12 PM, Leon Woestenberg wrote:
> Hello Andreas, all,
>
> On Mon, Mar 22, 2010 at 9:16 PM, Andreas Bombe<aeb@...ian.org>  wrote:
>> On Mon, Mar 22, 2010 at 08:18:49PM +0100, Leon Woestenberg wrote:
>>> What is the current solution for that particular problem, i.e. how
>>> should I make sure host memory writes are committed before I have an
>>> external DMA device act on it?
>>
>> The dma_sync_* functions, if you reuse DMA buffers without unmapping,
>> take care of that.  Otherwise the process of mapping them handles it.
>>
> The mapping makes the memory cache-coherent. I already use that.
>
> But does that mean that this coherency is guaranteed to occur before I
> start MMIO access to a device, i.e. is there a guaranteed ordering
> between the writes?

Well, for a streaming mapping, the device may not see the write to the 
memory at all until it's synced or unmapped (for one thing, if the 
kernel is using swiotlb to map the memory, it's an entirely different 
piece of memory and it needs to copy the data to where the device can 
actually see it).

For a coherent mapping, however, though I can't say for certain what the 
behavior is "supposed" to be, many drivers seem to depend on writes to 
these regions being ordered with respect to regular memory and would 
break if a particular platform didn't obey that.
--
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