kernel/drivers/dma, branch linux-5.1.y

dmaengine: imx-sdma: fix use-after-free on probe error path

2019-07-26T07:12:21Z

[ Upstream commit 2b8066c3deb9140fdf258417a51479b2aeaa7622 ] If probe() fails anywhere beyond the point where sdma_get_firmware() is called, then a kernel oops may occur. Problematic sequence of events: 1. probe() calls sdma_get_firmware(), which schedules the firmware callback to run when firmware becomes available, using the sdma instance structure as the context 2. probe() encounters an error, which deallocates the sdma instance structure 3. firmware becomes available, firmware callback is called with deallocated sdma instance structure 4. use after free - kernel oops ! Solution: only attempt to load firmware when we're certain that probe() will succeed. This guarantees that the firmware callback's context will remain valid. Note that the remove() path is unaffected by this issue: the firmware loader will increment the driver module's use count, ensuring that the module cannot be unloaded while the firmware callback is pending or running. Signed-off-by: Sven Van Asbroeck Reviewed-by: Robin Gong [vkoul: fixed braces for if condition] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: jz4780: Fix an endian bug in IRQ handler

2019-07-10T07:52:32Z

commit 4c89cc73d1da42ae48b5c5dfbfd12304d0b86786 upstream. The "pending" variable was a u32 but we cast it to an unsigned long pointer when we do the for_each_set_bit() loop. The problem is that on big endian 64bit systems that results in an out of bounds read. Fixes: 4e4106f5e942 ("dmaengine: jz4780: Fix transfers being ACKed too soon") Signed-off-by: Dan Carpenter Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: imx-sdma: remove BD_INTR for channel0

2019-07-10T07:52:32Z

commit 3f93a4f297961c12bb17aa16cb3a4d1291823cae upstream. It is possible for an irq triggered by channel0 to be received later after clks are disabled once firmware loaded during sdma probe. If that happens then clearing them by writing to SDMA_H_INTR won't work and the kernel will hang processing infinite interrupts. Actually, don't need interrupt triggered on channel0 since it's pollling SDMA_H_STATSTOP to know channel0 done rather than interrupt in current code, just clear BD_INTR to disable channel0 interrupt to avoid the above case. This issue was brought by commit 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") which didn't take care the above case. Fixes: 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") Cc: stable@vger.kernel.org #5.0+ Signed-off-by: Robin Gong Reported-by: Sven Van Asbroeck Tested-by: Sven Van Asbroeck Reviewed-by: Michael Olbrich Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: qcom: bam_dma: Fix completed descriptors count

2019-07-10T07:52:32Z

commit f6034225442c4a87906d36e975fd9e99a8f95487 upstream. One space is left unused in circular FIFO to differentiate 'full' and 'empty' cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: stable@vger.kernel.org Reported-by: Srinivas Kandagatla Signed-off-by: Sricharan R Tested-by: Srinivas Kandagatla Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: sprd: Fix the right place to configure 2-stage transfer

2019-06-25T03:34:48Z

[ Upstream commit c434e377dad1dec05cad1870ce21bc539e1e024f ] Move the 2-stage configuration before configuring the link-list mode, since we will use some 2-stage configuration to fill the link-list configuration. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix block length overflow

2019-06-25T03:34:48Z

[ Upstream commit 89d03b3c126d683f7b2cd5b07178493993d12448 ] The maximum value of block length is 0xffff, so if the configured transfer length is more than 0xffff, that will cause block length overflow to lead a configuration error. Thus we can set block length as the maximum burst length to avoid this issue, since the maximum burst length will not be a big value which is more than 0xffff. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix the incorrect start for 2-stage destination channels

2019-06-25T03:34:48Z

[ Upstream commit 3d626a97f0303e9c30d063434b749de3f0f91fb5 ] The 2-stage destination channel will be triggered by source channel automatically, which means we should not trigger it by software request. Signed-off-by: Eric Long Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Add validation of current descriptor in irq handler

2019-06-25T03:34:48Z

[ Upstream commit 58152b0e573e5581c4b9ef7cf06d2e9fafae27d4 ] When user terminates one DMA channel to free all its descriptors, but at the same time one transaction interrupt was triggered possibly, now we should not handle this interrupt by validating if the 'schan->cur_desc' was set as NULL to avoid crashing the kernel. Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: sprd: Fix the possible crash when getting descriptor status

2019-06-25T03:34:48Z

[ Upstream commit 16d0f85e45b99411ac10cb12cdd9279204a72381 ] We will get a NULL virtual descriptor by vchan_find_desc() when the descriptor has been submitted, that will crash the kernel when getting the descriptor status. In this case, since the descriptor has been submitted to process, but it is not completed now, which means the descriptor is listed into the 'vc->desc_submitted' list now. So we can not get current processing descriptor by vchan_find_desc(), but the pointer 'schan->cur_desc' will point to the current processing descriptor, then we can use 'schan->cur_desc' to get current processing descriptor's status to avoid this issue. Signed-off-by: Baolin Wang Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: mediatek-cqdma: sleeping in atomic context

2019-06-25T03:34:47Z

[ Upstream commit 069b3c4214f27b130d0642f32438560db30f452e ] The mtk_cqdma_poll_engine_done() function takes a true/false parameter where true means it's called from atomic context. There are a couple places where it was set to false but it's actually in atomic context so it should be true. All the callers for mtk_cqdma_hard_reset() are holding a spin_lock and in mtk_cqdma_free_chan_resources() we take a spin_lock before calling the mtk_cqdma_poll_engine_done() function. Fixes: b1f01e48df5a ("dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC") Signed-off-by: Dan Carpenter Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin