| Message ID | TYCP286MB1188FEE149369A32D90DCE288A21A@TYCP286MB1188.JPNP286.PROD.OUTLOOK.COM |
|---|---|
| State | New |
| Headers | show |
| Series | ALSA: dummy: Fix &dpcm->lock deadlock issues | expand |
On Sun, 25 Jun 2023 17:35:48 +0200, YE Chengfeng wrote: > > The timer dummy_systimer_callback is executed under softirq > context, thus other process context code requiring the same lock > should disable interrupt. Otherwise there would be potential > deadlock issues when the code executing under process context > (i.e., dummy_systimer_pointer, dummy_systimer_start, > dummy_systimer_stop) is preempted by the timer while holding > the lock. > > Deadlock scenario: > dummy_systimer_pointer > -> spin_lock(&dpcm->lock); > <timer interrupt> > -> dummy_systimer_callback > -> spin_lock_irqsave(&dpcm->lock, flags); > > Fix the potential deadlock by using spin_lock_irqsave. Did you really trigger this deadlock, or is just your hypothesis? I'm asking it because basically the deadlock above shouldn't happen; those are called only via PCM trigger and pointer callbacks, and they are always called inside the PCM stream lock, and already irq-disabled. thanks, Takashi
These bugs are detected by an experimental static analyzer that I am implementing, and I didn't realize that callbacks are already irq-disabled while doing manually confirmation. So sorry for bothering you for these false positive reports. Perhaps next time I should mention the bugs are detected statically and be careful of these cases. Thanks so much, Chengfeng
Hi Takashi, Sorry for interrupt you again after such a long time. I just notice there was an old patch posted[1] from you that made pcm pointer() and trigger() callbacks could being able to be executed under non-atomic context, by using mutex instead of spin_lock_irq(). I find several similar deadlocks like this one on other places(inside pointer() and trigger() callbacks and being interrupted by hardirq), I am confusing whether they could be real deadlocks, as if these callbacks are executed under non-atomic context then they could be real problem. Thanks much if you are available to reply, Chengfeng [1] https://patchwork.kernel.org/project/alsa-devel/patch/1409572832-32553-2-git-send-email-tiwai@suse.de/
diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index 9c17b49a2ae1..04fb4f17e05c 100644 --- a/sound/drivers/dummy.c +++ b/sound/drivers/dummy.c @@ -268,19 +268,23 @@ static void dummy_systimer_update(struct dummy_systimer_pcm *dpcm) static int dummy_systimer_start(struct snd_pcm_substream *substream) { struct dummy_systimer_pcm *dpcm = substream->runtime->private_data; - spin_lock(&dpcm->lock); + unsigned long flags; + + spin_lock_irqsave(&dpcm->lock, flags); dpcm->base_time = jiffies; dummy_systimer_rearm(dpcm); - spin_unlock(&dpcm->lock); + spin_unlock_irqrestore(&dpcm->lock, flags); return 0; } static int dummy_systimer_stop(struct snd_pcm_substream *substream) { struct dummy_systimer_pcm *dpcm = substream->runtime->private_data; - spin_lock(&dpcm->lock); + unsigned long flags; + + spin_lock_irqsave(&dpcm->lock, flags); del_timer(&dpcm->timer); - spin_unlock(&dpcm->lock); + spin_unlock_irqrestore(&dpcm->lock, flags); return 0; } @@ -320,11 +324,12 @@ dummy_systimer_pointer(struct snd_pcm_substream *substream) { struct dummy_systimer_pcm *dpcm = substream->runtime->private_data; snd_pcm_uframes_t pos; + unsigned long flags; - spin_lock(&dpcm->lock); + spin_lock_irqsave(&dpcm->lock, flags); dummy_systimer_update(dpcm); pos = dpcm->frac_pos / HZ; - spin_unlock(&dpcm->lock); + spin_unlock_irqrestore(&dpcm->lock, flags); return pos; }
The timer dummy_systimer_callback is executed under softirq context, thus other process context code requiring the same lock should disable interrupt. Otherwise there would be potential deadlock issues when the code executing under process context (i.e., dummy_systimer_pointer, dummy_systimer_start, dummy_systimer_stop) is preempted by the timer while holding the lock. Deadlock scenario: dummy_systimer_pointer -> spin_lock(&dpcm->lock); <timer interrupt> -> dummy_systimer_callback -> spin_lock_irqsave(&dpcm->lock, flags); Fix the potential deadlock by using spin_lock_irqsave. Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk> --- sound/drivers/dummy.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)