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?
