/* * Copyright 2013, Michael Ellerman, IBM Corp. * Licensed under GPLv2. */ #include .text FUNC_START(thirty_two_instruction_loop) cmpdi r3,0 beqlr addi r4,r3,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 addi r4,r4,1 # 28 addi's subi r3,r3,1 b FUNC_NAME(thirty_two_instruction_loop) FUNC_END(thirty_two_instruction_loop) e id='header'> cgit logo index : net-next.git
net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/sound/soc/sunxi/sun4i-codec.c
diff options
context:
space:
mode:
authorIago Abal <mail@iagoabal.eu>2017-01-11 14:00:21 +0100
committerVinod Koul <vinod.koul@intel.com>2017-01-25 15:35:11 +0530
commit91539eb1fda2d530d3b268eef542c5414e54bf1a (patch)
tree960f5ca6342ad20837aff18aad6e8ecd7da32fd6 /sound/soc/sunxi/sun4i-codec.c
parent6610d0edf6dc7ee97e46ab3a538a565c79d26199 (diff)
dmaengine: pl330: fix double lock
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 <mail@iagoabal.eu> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'sound/soc/sunxi/sun4i-codec.c')