Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754743Ab2KMJjW (ORCPT ); Tue, 13 Nov 2012 04:39:22 -0500 Received: from mail-ea0-f174.google.com ([209.85.215.174]:40538 "EHLO mail-ea0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754292Ab2KMJjS (ORCPT ); Tue, 13 Nov 2012 04:39:18 -0500 Message-ID: <50A21542.2090102@suse.cz> Date: Tue, 13 Nov 2012 10:39:14 +0100 From: Jiri Slaby User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Takashi Iwai CC: Jaroslav Kysela , alsa-devel@alsa-project.org, LKML , USB list , Jiri Slaby Subject: Re: Sound+USB: deadlock problem References: <50A20429.3020109@suse.cz> <50A20512.10805@suse.cz> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7223 Lines: 173 On 11/13/2012 09:45 AM, Takashi Iwai wrote: > At Tue, 13 Nov 2012 09:30:10 +0100, > Jiri Slaby wrote: >> >> On 11/13/2012 09:28 AM, Takashi Iwai wrote: >>> At Tue, 13 Nov 2012 09:26:17 +0100, >>> Jiri Slaby wrote: >>>> >>>> Hello, >>>> >>>> I've just plugged+unplugged+plugged my USB audio card and the audio >>>> subsystem got stuck: >>> >>> Which kernel? If it's older than 3.7-rc5, could you try 3.7-rc5? >> >> Oh, forgot to mention: >> 3.7.0-rc5-next-20121112_64+ > > Through a quick glance, one of mutex locks seems stuck. > Just a blind short -- does the patch below cure the problem? Yes, this helps. Adding a LOCKDEP splash _before_ applying the patch: ====================================================== [ INFO: possible circular locking dependency detected ] 3.7.0-rc5-next-20121112_64-ldep+ #15 Not tainted ------------------------------------------------------- khubd/446 is trying to acquire lock: (&pcm->open_mutex){+.+.+.}, at: [] snd_pcm_dev_disconnect+0x45/0x1f0 but task is already holding lock: (register_mutex#2){+.+.+.}, at: [] snd_pcm_dev_disconnect+0x23/0x1f0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (register_mutex#2){+.+.+.}: [] lock_acquire+0x5a/0x70 [] mutex_lock_nested+0x69/0x3a0 [] snd_pcm_dev_disconnect+0x23/0x1f0 [] snd_device_disconnect+0x62/0xa0 [] snd_device_disconnect_all+0x3c/0x60 [] snd_card_disconnect+0x147/0x1d0 [] usb_audio_disconnect+0x98/0x1d0 [] usb_unbind_interface+0x5e/0x1a0 [] __device_release_driver+0x77/0xe0 [] device_release_driver+0x29/0x40 [] bus_remove_device+0xfa/0x170 [] device_del+0x127/0x1c0 [] usb_disable_device+0xb0/0x270 [] usb_disconnect+0xad/0x160 [] hub_thread+0x71c/0x1730 [] kthread+0xd6/0xe0 [] ret_from_fork+0x7c/0xb0 -> #1 (&chip->shutdown_rwsem){++++++}: [] lock_acquire+0x5a/0x70 [] down_read+0x47/0x5c [] snd_usb_autoresume+0x2c/0x60 [] snd_usb_pcm_open+0x20f/0x4a0 [] snd_usb_playback_open+0xb/0x10 [] snd_pcm_open_substream+0x4e/0x90 [] snd_pcm_open+0xb2/0x250 [] snd_pcm_playback_open+0x43/0x70 [] snd_open+0xba/0x200 [] chrdev_open+0x96/0x1c0 [] do_dentry_open.isra.16+0x1e6/0x280 [] finish_open+0x36/0x70 [] do_last.isra.64+0x2ce/0xcc0 [] path_openat.isra.65+0xb3/0x4d0 [] do_filp_open+0x3c/0x90 [] do_sys_open+0xef/0x1d0 [] sys_open+0x1c/0x20 [] system_call_fastpath+0x16/0x1b -> #0 (&pcm->open_mutex){+.+.+.}: [] __lock_acquire+0x1c38/0x1c40 [] lock_acquire+0x5a/0x70 [] mutex_lock_nested+0x69/0x3a0 [] snd_pcm_dev_disconnect+0x45/0x1f0 [] snd_device_disconnect+0x62/0xa0 [] snd_device_disconnect_all+0x3c/0x60 [] snd_card_disconnect+0x147/0x1d0 [] usb_audio_disconnect+0x98/0x1d0 [] usb_unbind_interface+0x5e/0x1a0 [] __device_release_driver+0x77/0xe0 [] device_release_driver+0x29/0x40 [] bus_remove_device+0xfa/0x170 [] device_del+0x127/0x1c0 [] usb_disable_device+0xb0/0x270 [] usb_disconnect+0xad/0x160 [] hub_thread+0x71c/0x1730 [] kthread+0xd6/0xe0 [] ret_from_fork+0x7c/0xb0 other info that might help us debug this: Chain exists of: &pcm->open_mutex --> &chip->shutdown_rwsem --> register_mutex#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(register_mutex#2); lock(&chip->shutdown_rwsem); lock(register_mutex#2); lock(&pcm->open_mutex); *** DEADLOCK *** 6 locks held by khubd/446: #0: (&__lockdep_no_validate__){......}, at: [] hub_thread+0xde/0x1730 #1: (&__lockdep_no_validate__){......}, at: [] usb_disconnect+0x61/0x160 #2: (&__lockdep_no_validate__){......}, at: [] device_release_driver+0x21/0x40 #3: (register_mutex#5){+.+.+.}, at: [] usb_audio_disconnect+0x35/0x1d0 #4: (&chip->shutdown_rwsem){++++++}, at: [] usb_audio_disconnect+0x45/0x1d0 #5: (register_mutex#2){+.+.+.}, at: [] snd_pcm_dev_disconnect+0x23/0x1f0 stack backtrace: Pid: 446, comm: khubd Not tainted 3.7.0-rc5-next-20121112_64-ldep+ #15 Call Trace: [] print_circular_bug+0x1fb/0x20c [] __lock_acquire+0x1c38/0x1c40 [] ? snd_unregister_oss_device+0x9e/0x120 [] lock_acquire+0x5a/0x70 [] ? snd_pcm_dev_disconnect+0x45/0x1f0 [] mutex_lock_nested+0x69/0x3a0 [] ? snd_pcm_dev_disconnect+0x45/0x1f0 [] snd_pcm_dev_disconnect+0x45/0x1f0 [] snd_device_disconnect+0x62/0xa0 [] snd_device_disconnect_all+0x3c/0x60 [] snd_card_disconnect+0x147/0x1d0 [] usb_audio_disconnect+0x98/0x1d0 [] usb_unbind_interface+0x5e/0x1a0 [] __device_release_driver+0x77/0xe0 [] device_release_driver+0x29/0x40 [] bus_remove_device+0xfa/0x170 [] device_del+0x127/0x1c0 [] ? usb_disconnect+0x61/0x160 [] usb_disable_device+0xb0/0x270 [] usb_disconnect+0xad/0x160 [] hub_thread+0x71c/0x1730 [] ? trace_hardirqs_on_caller+0x10d/0x1e0 [] ? __init_waitqueue_head+0x60/0x60 [] ? usb_remote_wakeup+0x70/0x70 [] kthread+0xd6/0xe0 [] ? _raw_spin_unlock_irq+0x2b/0x50 [] ? kthread_create_on_node+0x140/0x140 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x140/0x140 -- js suse labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/