linux-kernel - Re: [RFC] dma: passing "attributes" to dma_map

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]

Date:	Fri, 21 Dec 2007 21:24:25 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	akepner@....com
CC:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	grundler@...isc-linux.org, jbarnes@...tuousgeek.org, jes@....com,
	randy.dunlap@...cle.com, rdreier@...co.com,
	James.Bottomley@...eleye.com, davem@...emloft.net,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] dma: passing "attributes" to dma_map_* routines

akepner@....com wrote:
> On Fri, Dec 21, 2007 at 07:56:25AM +1100, Benjamin Herrenschmidt wrote:
>> ...
>> Can't you just have a primitive to sync things up that you call
>> explicitely from your driver after fetching a new status entry ?
> 
> Well, the only mechanisms I know to get things synced are the ones 
> I mentioned before: 1) generate an interrupt, 2) write to memory 
> which has the "barrier" attribute. Obviously 1 is out - giving  
> the memory used for status indications the barrier attribute is 
> the most primitive means I'm aware of.

I don't know what it is in detail what Arthur et al are facing, but this
is how it looks to me:

A sync call like Benjamin suggests has two preconditions.

  1. The interconnect hardware actually offers such a functionality.
I.e. there is a way for the CPU to request flushing of pending DMAs, and
the interconnect is able to generate an interrupt to signal when it is done.

  2. The protocols which the devices use are suitable for this.  I.e.
 there are no race conditions during the window between when the DMAs
were flushed and when the CPU has finished reading the status memory area.

Even _if_ both is true, a regime with such a call would obviously be
more complex and might be harder to get to perform well, compared to the
regime where the interconnect hardware is told beforehand that some
particular DMA writes must never be reordered relative to earlier and
later DMA writes.
-- 
Stefan Richter
-=====-=-=== ==-- =-=-=
http://arcgraph.de/sr/
--
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/