public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
@ 2023-06-25 15:35 YE Chengfeng
  2023-06-25 18:13 ` Takashi Iwai
  0 siblings, 1 reply; 4+ messages in thread
From: YE Chengfeng @ 2023-06-25 15:35 UTC (permalink / raw)
  To: perex@perex.cz, tiwai@suse.com, yunjunlee@chromium.org
  Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org

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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
  2023-06-25 15:35 [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues YE Chengfeng
@ 2023-06-25 18:13 ` Takashi Iwai
       [not found]   ` <TYCP286MB1188D860B56B9FF1FCAA79148A26A@TYCP286MB1188.JPNP286.PROD.OUTLOOK.COM>
  0 siblings, 1 reply; 4+ messages in thread
From: Takashi Iwai @ 2023-06-25 18:13 UTC (permalink / raw)
  To: YE Chengfeng
  Cc: perex@perex.cz, tiwai@suse.com, yunjunlee@chromium.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* 回复: [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
       [not found]   ` <TYCP286MB1188D860B56B9FF1FCAA79148A26A@TYCP286MB1188.JPNP286.PROD.OUTLOOK.COM>
@ 2023-09-17 17:26     ` YE Chengfeng
  2023-09-18 15:53       ` Takashi Iwai
  0 siblings, 1 reply; 4+ messages in thread
From: YE Chengfeng @ 2023-09-17 17:26 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: perex@perex.cz, tiwai@suse.com, yunjunlee@chromium.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 回复: [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues
  2023-09-17 17:26     ` 回复: " YE Chengfeng
@ 2023-09-18 15:53       ` Takashi Iwai
  0 siblings, 0 replies; 4+ messages in thread
From: Takashi Iwai @ 2023-09-18 15:53 UTC (permalink / raw)
  To: YE Chengfeng
  Cc: perex@perex.cz, tiwai@suse.com, yunjunlee@chromium.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org

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-send-email-tiwai@suse.de/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-09-18 16:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-25 15:35 [PATCH] ALSA: dummy: Fix &dpcm->lock deadlock issues YE Chengfeng
2023-06-25 18:13 ` Takashi Iwai
     [not found]   ` <TYCP286MB1188D860B56B9FF1FCAA79148A26A@TYCP286MB1188.JPNP286.PROD.OUTLOOK.COM>
2023-09-17 17:26     ` 回复: " YE Chengfeng
2023-09-18 15:53       ` Takashi Iwai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox