#ifndef SOUND_FIREWIRE_LIB_H_INCLUDED #define SOUND_FIREWIRE_LIB_H_INCLUDED #include #include #include #include struct fw_unit; #define FW_GENERATION_MASK 0x00ff #define FW_FIXED_GENERATION 0x0100 #define FW_QUIET 0x0200 int snd_fw_transaction(struct fw_unit *unit, int tcode, u64 offset, void *buffer, size_t length, unsigned int flags); /* returns true if retrying the transaction would not make sense */ static inline bool rcode_is_permanent_error(int rcode) { return rcode == RCODE_TYPE_ERROR || rcode == RCODE_ADDRESS_ERROR; } void snd_fw_schedule_registration(struct fw_unit *unit, struct delayed_work *dwork); struct snd_fw_async_midi_port; typedef int (*snd_fw_async_midi_port_fill)( struct snd_rawmidi_substream *substream, u8 *buf); struct snd_fw_async_midi_port { struct fw_device *parent; struct work_struct work; bool idling; ktime_t next_ktime; bool error; u64 addr; struct fw_transaction transaction; u8 *buf; unsigned int len; struct snd_rawmidi_substream *substream; snd_fw_async_midi_port_fill fill; unsigned int consume_bytes; }; int snd_fw_async_midi_port_init(struct snd_fw_async_midi_port *port, struct fw_unit *unit, u64 addr, unsigned int len, snd_fw_async_midi_port_fill fill); void snd_fw_async_midi_port_destroy(struct snd_fw_async_midi_port *port); /** * snd_fw_async_midi_port_run - run transactions for the async MIDI port * @port: the asynchronous MIDI port * @substream: the MIDI substream */ static inline void snd_fw_async_midi_port_run(struct snd_fw_async_midi_port *port, struct snd_rawmidi_substream *substream) { if (!port->error) { port->substream = substream; schedule_work(&port->work); } } /** * snd_fw_async_midi_port_finish - finish the asynchronous MIDI port * @port: the asynchronous MIDI port */ static inline void snd_fw_async_midi_port_finish(struct snd_fw_async_midi_port *port) { port->substream = NULL; port->error = false; } #endif d=91539eb1fda2d530d3b268eef542c5414e54bf1a'>diff
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/sh/rcar
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/sh/rcar')