Re: [PATCH 2/2] ARM: dts: imx7: add DMA properties for ECSPI

[Trent Piepho]

On Tue, 2019-02-12 at 22:57 -0200, Fabio Estevam wrote:
> On Tue, Feb 12, 2019 at 10:07 PM Trent Piepho <tpiepho@xxxxxxxxxx>
> wrote:
> 
> > Tried SDMA firmware 4.2.  Still broken.  No apparent change.
> > 
> > Get 4 cycle pause after each byte.
> > 
> > And crash while/after using DMA.  Clearly some sort of memory
> > corruption going on.  Fortunately, it's very reliable that using
> > DMA
> > almost immediately causes a problem and this is easy to
> > reproduce.  I
> > think that indicates it's either clobbers a lot of RAM, or
> > consistently
> > manages to hit a very important location for kernel memory
> > allocators.
> > 
> > I've got an idea of where that might be happening that I'm looking
> > into.
> 
> Ok, thanks for investigating this issue.
> 
> > 
> > I think it's reasonable to add the dma attributes, but put a check
> > in
> > the spi-imx driver to disable DMA on imx7d at least.
> 
> Something like this?
http://dark-code.bulix.org/urfoh8-580174

Something like that.  I thought a printk on probe, that DMA was
disabled, would be nice so no one beats their head against the wall
trying to figure out why DMA isn't being used.

But I think I've found the issue and tracked it to bug in the spi core.
  I'll send a patch shortly.  It should affect anything that uses DMA,
with a spi master that requires RX and/or TX buffers, and a spi
transfer that does not provide the require buffer(s).  In my case, spi-
imx requires an RX buffer but I am doing TX only DMA.  The spi core
takes care of this, but I think there is a race in the cleanup of the
dummy RX DMA buffer.

This appears to clobber something relating to DMA buffer allocation and
the kernel starts to allocate bogus DMA buffer addresses, and the SPI
controller happily DMAs all over memory.  I wonder if that could be
somehow exploited to read/write arbitrary memory via SPI DMA?