ALSA: dummy: Fix &dpcm->lock deadlock issues

Commit Message

YE Chengfeng June 25, 2023, 3:35 p.m. UTC

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 <[e-mail]>
---
 sound/drivers/dummy.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

Comments

Takashi Iwai June 25, 2023, 6:13 p.m. UTC | #1

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

YE Chengfeng June 26, 2023, 10:51 a.m. UTC | #2

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

YE Chengfeng Sept. 17, 2023, 5:26 p.m. UTC | #3

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/[e-mail]/

Takashi Iwai Sept. 18, 2023, 3:53 p.m. UTC | #4

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/[e-mail]/

Patch

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;
 }