Takashi Sakamoto wrote:
(Apr 4 2014 06:20), Clemens Ladisch wrote:
+++ b/sound/firewire/fireworks/fireworks_midi.c +static int midi_capture_open(struct snd_rawmidi_substream *substream) +{
- struct snd_efw *efw = substream->rmidi->private_data;
- efw->capture_substreams++;
The MIDI .open callback is not synchronized with the PCM callbacks; this might race and must be protected with a mutex.
Exactly. And I've realized it.
The race appears between some processes to handle substream counter at the same time. The counter is changed by below operations: PCM .hw_param/.hw_free MIDI .open/.close
Well, for this issue, I think it better to use atomic_t for substream counter than mutex. The way to use mutex is propper for MIDI .open/ .close because these functions also execure stream_start_duplex() / stream_stop_duplex() (then I must move mutex_lock/mutex_unlock from stream.c). But PCM .hw_param/.hw_free just increment / decrement substream counter. I think it consts expensive than such simple operation.
The fast path of mutex_(un)lock already is quite heavily optimized. Optimizations should not be added unless they are actually needed; in this case, the difference would not be noticeable, especially because none of these functions are called frequently. (But if the code using atomic_t ends up being simpler, there's no reason not to use it.)
Regards, Clemens