[alsa-devel] ALSA hang on 4.13.0-rc7

[Takashi Iwai]

On Wed, 30 Aug 2017 14:33:36 +0200,
Takashi Iwai wrote:
> 
> On Wed, 30 Aug 2017 14:26:51 +0200,
> Markus Trippelsdorf wrote:
> > 
> > On 2017.08.30 at 13:46 +0200, Takashi Iwai wrote:
> > > On Wed, 30 Aug 2017 13:42:41 +0200,
> > > Markus Trippelsdorf wrote:
> > > > 
> > > > On 2017.08.30 at 13:34 +0200, Takashi Iwai wrote:
> > > > > On Wed, 30 Aug 2017 13:33:40 +0200,
> > > > > Markus Trippelsdorf wrote:
> > > > > > 
> > > > > > On 2017.08.30 at 13:23 +0200, Takashi Iwai wrote:
> > > > > > > On Wed, 30 Aug 2017 12:03:34 +0200,
> > > > > > > Markus Trippelsdorf wrote:
> > > > > > > > 
> > > > > > > > On my system ALSA sometimes hangs:
> > > > > > > > 
> > > > > > > >  sysrq: SysRq : Show Blocked State                                         
> > > > > > > >    task                        PC stack   pid father                       
> > > > > > > >  output:ALSA def D    0   171      1 0x00000000                            
> > > > > > > >  Call Trace:                  
> > > > > > > >   ? __schedule+0x17c/0x720    
> > > > > > > >   ? schedule_preempt_disabled+0x2d/0x80                                    
> > > > > > > >   ? __mutex_lock_slowpath+0x141/0x420                                      
> > > > > > > >   ? snd_pcm_common_ioctl1+0x2f/0x1400                                      
> > > > > > > >   ? snd_pcm_common_ioctl1+0x2f/0x1400                                      
> > > > > > > >   ? snd_card_file_remove+0x76/0x120                                        
> > > > > > > >   ? snd_pcm_playback_ioctl+0x1c7/0x560                                     
> > > > > > > >   ? dput+0xb6/0x1e0           
> > > > > > > >   ? SyS_ioctl+0xa7/0x860      
> > > > > > > >   ? task_work_run+0x70/0xa0   
> > > > > > > >   ? entry_SYSCALL_64_fastpath+0x13/0x94  
> > > > > > > > 
> > > > > > > > Only a reboot will fix the issue.
> > > > > > > 
> > > > > > > Is this a regression?
> > 
> > The issue started with:
> > 
> > commit 68b4acd322494444803a3f49884ae889c8ec6689 (HEAD, refs/bisect/bad)
> > Author: Takashi Iwai <tiwai at suse.de>
> > Date:   Tue May 24 15:07:39 2016 +0200
> > 
> >     ALSA: pcm: Apply power lock globally to common ioctls
> 
> Thanks, that looks fitting with your problem description.
> I'll take a deeper look.

Could you try the patch below?


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai at suse.de>
Subject: [PATCH] ALSA: pcm: Fix power lock unbalance via OSS emulation

PCM OSS emulation issues the drain ioctl without power lock.  It used
to work in the earlier kernels as the power lock was taken inside
snd_pcm_drain() itself.  But since 68b4acd32249 ("ALSA: pcm: Apply
power lock globally to common ioctls"), the power lock is taken
outside the function.  Due to that change, the call via OSS emulation
leads to the unbalanced power lock, thus it deadlocks.

As a quick fix, just take the power lock before snd_pcm_drain() call
for OSS emulation path.  A better cleanup will follow later.

Fixes: 68b4acd32249 ("ALSA: pcm: Apply power lock globally to common ioctls")
Reported-by: Markus Trippelsdorf <markus at trippelsdorf.de>
Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/core/pcm_native.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 22995cb3bd44..cf0433f80067 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3064,6 +3064,7 @@ int snd_pcm_kernel_ioctl(struct snd_pcm_substream *substream,
 {
 	snd_pcm_uframes_t *frames = arg;
 	snd_pcm_sframes_t result;
+	int err;
 	
 	switch (cmd) {
 	case SNDRV_PCM_IOCTL_FORWARD:
@@ -3083,7 +3084,10 @@ int snd_pcm_kernel_ioctl(struct snd_pcm_substream *substream,
 	case SNDRV_PCM_IOCTL_START:
 		return snd_pcm_start_lock_irq(substream);
 	case SNDRV_PCM_IOCTL_DRAIN:
-		return snd_pcm_drain(substream, NULL);
+		snd_power_lock(substream->pcm->card);
+		err = snd_pcm_drain(substream, NULL);
+		snd_power_unlock(substream->pcm->card);
+		return err;
 	case SNDRV_PCM_IOCTL_DROP:
 		return snd_pcm_drop(substream);
 	case SNDRV_PCM_IOCTL_DELAY:
-- 
2.14.1