On Wed, May 18, 2011 at 07:36:54PM +0200, Marek Vasut wrote:
> > On Wed, May 18, 2011 at 05:18:38PM +0200, Pavel Herrmann wrote:
> > > spi_sync call uses its spi_message parameter to keep completion
> > > information, having this structure static is not thread-safe,
> > > potentially causing one thread having pointers to memory on or above
> > > other threads stack. use per-call spi_message on stack to fix this
> > I assume this has not been tested with DMA debugging enabled.
> > The DMA API does not like mapping memory from the stack, which is what
> > you're potentially doing with this:
> Yikes, good catch, but kmallocing this and kfreeing it again is not
> something I'd like to see either.
You could use a semaphore to protect against other threads.
However, this driver just gives us yet more problems, as it overlaps
the DMA'd data with the DMA metadata (spi message/spi transfer
structures.) And yes we do get bug reports on that too...
I think its about time driver and subsystem authors got a clue about
DMA incoherent architectures, and these things called 'cache lines'
which have a direct impact on whether code is buggy or not. Sharing
cache lines between DMA buffers and other data is Really Bad News for
data integrity - even sharing a cache line between two DMA buffers
can be a problem.
Zaurus-devel mailing list