Date: Wed, 26 Apr 2023 10:14:13 +0200
Message-ID: <87leifjc16.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org,
	linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	regressions@lists.linux.dev
Subject: Re: USB sound card freezes USB after resume from suspend
In-Reply-To: <7645c6c8-a21c-23d7-5c19-cd2892b98481@perex.cz>
References: <20230425111924.05cf8b13@kernel.org>
	<87pm7rtdul.wl-tiwai@suse.de>
	<7645c6c8-a21c-23d7-5c19-cd2892b98481@perex.cz>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII

On Wed, 26 Apr 2023 10:01:11 +0200,
Jaroslav Kysela wrote:
> 
> On 26. 04. 23 7:24, Takashi Iwai wrote:
> > On Tue, 25 Apr 2023 20:19:24 +0200,
> > Jakub Kicinski wrote:
> >> 
> >> Hi!
> >> 
> >> For a few weeks now I can't use any USB devices if I suspend my laptop
> >> with my USB sound card active and resuming it without it connected.
> >> 
> >> USB worker threads seems to be sitting in:
> >> 
> >> [<0>] snd_pcm_dev_disconnect+0x1e8/0x280 [snd_pcm]
> >> [<0>] snd_device_disconnect_all+0x42/0x80 [snd]
> >> [<0>] snd_card_disconnect+0x128/0x290 [snd]
> >> [<0>] usb_audio_disconnect+0x11a/0x2c0 [snd_usb_audio]
> >> [<0>] usb_unbind_interface+0x8c/0x270
> >> [<0>] device_release_driver_internal+0x1b2/0x230
> >> [<0>] bus_remove_device+0xd8/0x150
> >> [<0>] device_del+0x18b/0x410
> >> [<0>] usb_disable_device+0xc6/0x1e0
> >> [<0>] usb_disconnect+0xda/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] usb_disconnect+0xbf/0x2c0
> >> [<0>] hub_event+0xf01/0x1cd0
> >> [<0>] process_one_work+0x1c4/0x3d0
> >> [<0>] worker_thread+0x4d/0x380
> >> [<0>] kthread+0xe6/0x110
> >> [<0>] ret_from_fork+0x29/0x50
> >> 
> >> Which is:
> >> 
> >> snd_pcm_dev_disconnect (/usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:818 /usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:812 /usr/src/debug/kernel-6.2.12/linux-6.2.12-300.fc38.x86_64/sound/core/pcm.c:1129) snd_pcm
> >> 
> >> It happens on Fedora 37 and Fedora 38, it seems to have coincided with
> >> the 6.2 kernel but I'm not 100% sure.
> >> 
> >> The USB devices come back after half an hour or so, silently.
> >> There's nothing of note in dmesg.
> > 
> > AFAIK, there has been no similar report, so far.
> > 
> > Is it a regression?  If yes, could you figure out which kernel version
> > starts showing the problem (or at best bisection)?
> 
> It seems that it may be related to free_chmap():
> 
> (gdb) l *(snd_pcm_dev_disconnect+0x1e8)
> 0xef0 is in snd_pcm_dev_disconnect (sound/core/pcm.c:817).
> 812	static void free_chmap(struct snd_pcm_str *pstr)
> 813	{
> 814		if (pstr->chmap_kctl) {
> 815			struct snd_card *card = pstr->pcm->card;
> 816	
> 817			down_write(&card->controls_rwsem);
> 818			snd_ctl_remove(card, pstr->chmap_kctl);
> 819			up_write(&card->controls_rwsem);
> 820			pstr->chmap_kctl = NULL;
> 821		}
> 
> I think that the chmap should be freed only in snd_pcm_free_stream()
> to avoid possible nested mutex locks. This operation does not belong
> to disconnect.

A good point, it'll be a patch like below.
But we still need to figure out what's actually happening there.
 
> But I cannot reproduce this lock here.

Here too.  Could be tied with the config or the device?


thanks,

Takashi

-- 8< --
--- a/sound/core/pcm.c
+++ b/sound/core/pcm.c
@@ -1126,7 +1126,6 @@ static int snd_pcm_dev_disconnect(struct snd_device *device)
 	pcm_call_notify(pcm, n_disconnect);
 	for (cidx = 0; cidx < 2; cidx++) {
 		snd_unregister_device(&pcm->streams[cidx].dev);
-		free_chmap(&pcm->streams[cidx]);
 	}
 	mutex_unlock(&pcm->open_mutex);
 	mutex_unlock(&register_mutex);