Re: [RFC][PATCH] SPI subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 03, 2005 at 08:14:57AM -0700, David Brownell wrote:
> > From: Arjan van de Ven <[email protected]>
> > Date: Mon, 03 Oct 2005 13:07:36 +0200
> >
> > please NEVER EVER do dma from or to a stack variable. It's not allowed
> > on all architectures and it is really really bad practice in general
> > anyway. 
> 
> Arjan, could you mention some Linuxes which don't allow it?
> 
> Every time the topic of DMA to/from stack comes up, the advice is
> always to avoid it ... but so far as I recall, nobody's yet provided
> us with an example where it actually doesn't work.
> 
> Failing such examples, it's normal to discount such dire warnings and
> just plan to apply the relevant minor tweaks if/when they're needed.

I believe the issue is that you can't properly control the alignment
to ensure that you don't inadvertantly dirty the cache lines
corresponding with the memory you're performing DMA to/from.

Eg, on ARM, if the memory you're DMAing to/from is just above the
next stack location which will be used when you call a sub-function,
you'll have just undone the effects of the DMA API.  Provided GCC
decided to arrange the stack that way.

Or maybe there's a local variable right next to the DMA region.
Same effect.

However, who knows how different gcc versions will lay out the
stack?  That's completely up to the compilers whims.

So, if you want portable code and don't want random failures,
avoid DMA to/from the stack.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux