Message-ID: <20110322123311.GA24812@linuxtv.org>
Date:	Tue, 22 Mar 2011 13:33:11 +0100
From:	Johannes Stezenbach <js@...uxtv.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Florian Mickler <florian@...kler.org>,
	Andy Walls <awalls@...metrocast.net>, mchehab@...radead.org,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	tskd2@...oo.co.jp, liplianin@...by, g.marco@...enet.de,
	aet@...terburn.org, pb@...uxtv.org, mkrufky@...uxtv.org,
	nick@...k-andrew.net, max@...eto.com, janne-dvb@...nau.be,
	Oliver Neukum <oliver@...kum.org>,
	Greg Kroah-Hartman <greg@...ah.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Joerg Roedel <joerg.roedel@....com>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [PATCH 0/6] get rid of on-stack dma buffers

On Tue, Mar 22, 2011 at 11:59:32AM +0100, Jiri Kosina wrote:
> On Mon, 21 Mar 2011, Florian Mickler wrote:
> 
> > To be blunt, I'm not shure I fully understand the requirements myself. 
> > But as far as I grasped it, the main problem is that we need memory 
> > which the processor can see as soon as the device has scribbled upon it. 
> > (think caches and the like)
> > 
> > Somewhere down the line, the buffer to usb_control_msg get's to be a 
> > parameter to dma_map_single which is described as part of the DMA API in 
> > Documentation/DMA-API.txt
> > 
> > The main point I filter out from that is that the memory has to begin
> > exactly at a cache line boundary... 
> > 
> > I guess (not verified), that the dma api takes sufficient precautions to 
> > abort the dma transfer if a timeout happens.  So freeing _should_ not be 
> > an issue. (At least, I would expect big fat warnings everywhere if that 
> > were the case)
> > 
> > I cc'd some people that hopefully will correct me if I'm wrong...
> 
> It all boils down to making sure that you don't free the memory which is 
> used as target of DMA transfer.
> 
> This is very likely to hit you when DMA memory region is on stack, but 
> blindly just converting this to kmalloc()/kfree() isn't any better if you 
> don't make sure that all the DMA transfers have been finished and device 
> will not be making any more to that particular memory region.

I think it is important that one cache line is not shared between
a DMA buffer and other objects, especially on architectures where
cache coherency is managed in software (ARM, MIPS etc.).  If you
use kmalloc() for the DMA buffer that is guaranteed.
(E.g. DMA API will do writeback/invalidate before the DMA starts, but
if the CPU accesses a variable which is next to the buffer
while DMA is still pending then the whole cacheline is read back into
the cache.  If the CPU is then trying to read the DMA buffer after
the DMA finished it will see stale data from the cache.  You lose.)

It depends on the device doing DMA if it needs special alignment.
If you meet its alignment requirements, and wait for the end of the DMA before
returning, and make sure the buffer does not share cache lines with
neighbouring objects on the stack, then you can use DMA buffers on
stack.  In practice it's simpler and much less error prone to use kmalloc().

Regarding usb_control_msg(), since it is a synchronous API which
waits for the end of the transfer I'm relatively sure there is no
DMA pending when it returns, even if it aborts with timeout or any
other error code.


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