[PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
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(-)
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; }
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 ________________________________ 发件人: Takashi Iwai tiwai@suse.de 发送时间: 2023年6月26日 2:13 收件人: YE Chengfeng cyeaa@connect.ust.hk 抄送: perex@perex.cz perex@perex.cz; tiwai@suse.com tiwai@suse.com; yunjunlee@chromium.org yunjunlee@chromium.org; alsa-devel@alsa-project.org alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org 主题: Re: [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
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
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...
On Sun, 17 Sep 2023 19:26:13 +0200, YE Chengfeng wrote:
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.
It can't be a problem. The new code path with mutex() is enabled only when the PCM nonatomic flag is explicitly defined by the driver. And the dummy driver doesn't, i.e. it still uses the traditional atomic PCM ops, hence spin_lock() without the irq-save can be used fine in the atomic ops like pointer or trigger.
Takashi
Thanks much if you are available to reply, Chengfeng
[1] https://patchwork.kernel.org/project/alsa-devel/patch/1409572832-32553-2-git...
participants (2)
-
Takashi Iwai -
YE Chengfeng