linux-stable.git/drivers/dma, branch v4.9.69

dmaengine: pl330: fix double lock

2017-12-09T21:01:53+00:00

[ Upstream commit 91539eb1fda2d530d3b268eef542c5414e54bf1a ]

The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:

    Double lock:
    1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
    2. call to function `pl330_release_channel' immediately after;
    3. call to function `dma_pl330_rqcb' in line 1753;
    4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.

I have fixed it as suggested by Marek Szyprowski.

First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.

NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.

Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.

Signed-off-by: Iago Abal 
Reviewed-by: Marek Szyprowski 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status

2017-12-09T21:01:50+00:00

[ Upstream commit 57b5a32135c813f2ab669039fb4ec16b30cb3305 ]

chan->desc is always set to NULL when a DMA transfer is complete.
As a DMA transfer could be complete during the call of stm32_dma_tx_status,
we need to be sure that chan->desc is not NULL before using this variable
to avoid a null pointer deference issue.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Acked-by: Pierre-Yves MORDRET

dmaengine: stm32-dma: Set correct args number for DMA request from DT

2017-12-09T21:01:50+00:00

[ Upstream commit 7e96304d99477de1f70db42035071e56439da817 ]

This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.

Signed-off-by: M'boumba Cedric Madianga 
Reviewed-by: Ludovic BARRE 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: zx: set DMA_CYCLIC cap_mask bit

2017-11-30T08:39:11+00:00

[ Upstream commit fc318d64f3d91e15babac00e08354b1beb650b57 ]

The zx_dma driver supports cyclic transfer mode.  Let's set DMA_CYCLIC
cap_mask bit to make that clear, and avoid unnecessary failure when
clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC
bit set in mask.

Signed-off-by: Shawn Guo 
Reviewed-by: Jun Nie 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: dmatest: warn user when dma test times out

2017-11-24T07:33:42+00:00

commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream.

Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks). Ideally, this would be
cleaned up in the thread handler, but at the very least, the kernel
is left in a very precarious scenario that can lead to some long debug
sessions when the crash comes later.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Signed-off-by: Adam Wallis 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: ti-dma-crossbar: Fix possible race condition with dma_inuse

2017-10-18T07:35:38+00:00

commit 2ccb4837c938357233a0b8818e3ca3e58242c952 upstream.

When looking for unused xbar_out lane we should also protect the set_bit()
call with the same mutex to protect against concurrent threads picking the
same ID.

Fixes: ec9bfa1e1a796 ("dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr")
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: edma: Align the memcpy acnt array size with the transfer

2017-10-18T07:35:38+00:00

commit 87a2f622cc6446c7d09ac655b7b9b04886f16a4c upstream.

Memory to Memory transfers does not have any special alignment needs
regarding to acnt array size, but if one of the areas are in memory mapped
regions (like PCIe memory), we need to make sure that the acnt array size
is aligned with the mem copy parameters.

Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set
up in a different way: acnt == number of bytes in a word based on
__ffs((src | dest | len), bcnt and ccnt for looping the necessary number of
words to comlete the trasnfer.

Instead of reverting the commit we can fix it to make sure that the ACNT size
is aligned to the traswnfer.

Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation)
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Vinod Koul 
Signed-off-by: Greg Kroah-Hartman

dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.

2017-08-07T01:59:46+00:00

[ Upstream commit 75bdc7f31a3a6e9a12e218b31a44a1f54a91554c ]

Add some missing 'of_node_put()' in early exit error path.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: ioatdma: workaround SKX ioatdma version

2017-08-07T01:59:46+00:00

[ Upstream commit 34a31f0af84158955a9747fb5c6712da5bbb5331 ]

The Skylake ioatdma is technically CBDMA 3.2+ and contains the same hardware
bits with some additional 3.3 features, but it's not really 3.3 where the
driver is concerned.

Signed-off-by: Dave Jiang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

dmaengine: ioatdma: Add Skylake PCI Dev ID

2017-08-07T01:59:46+00:00

[ Upstream commit 1594c18fd297a8edcc72bc4b161f3f52603ebb92 ]

Adding Skylake Xeon PCI device ids for ioatdma and related bits.

Signed-off-by: Dave Jiang 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman