On Thu, Mar 22, 2018 at 10:08 PM, Frank Mori Hess <fmh6jj@xxxxxxxxx> wrote: > On Thu, Mar 22, 2018 at 4:45 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, Mar 21, 2018 at 09:46:56PM -0400, Frank Mori Hess wrote: >>> Hi Linux serial maintainers, >>> >>> There appears to be a bug in 8250_dma.c where __dma_rx_complete is >>> passed to the dmaengine as the completion callback for rx dma. >>> __dma_rx_complete does not lock the port spinlock (since it is also >>> called in contexts where the lock is already held). So a wrapper >>> around __dma_rx_complete which does lock the port spinlock should be >>> used as the completion callback instead. >> >> Can you write up a patch for this? >> > > Well, it's a little tricky. There's also the issue of insuring > __dma_rx_complete only runs once for a given transfer. Using > dma->rx_running for that is not enough, since it may very quickly get > set back to 1 after being cleared. Using dmaengine_synchronize or > similar would require getting out of atomic context, which I suppose > could be done if you disabled rx interrupts temporarily after a > timeout happens. > Another bug related to this, serial8250_release_dma() terminates any in-progress dma transfer but does not clear dma->rx_running. So if you kill a program that was in mid dma transfer, the next time you open the port it can have rx_running still set from the killed program. I've verified this problem using a 4.1.33 kernel, but looking at the latest kernel code it seems to have the same problem. -- Frank -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
