Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754121AbZAIHS7 (ORCPT ); Fri, 9 Jan 2009 02:18:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752355AbZAIHSv (ORCPT ); Fri, 9 Jan 2009 02:18:51 -0500 Received: from ns1.suse.de ([195.135.220.2]:46621 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751570AbZAIHSt (ORCPT ); Fri, 9 Jan 2009 02:18:49 -0500 Date: Fri, 09 Jan 2009 08:18:47 +0100 Message-ID: From: Takashi Iwai To: Wu Fengguang Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [bug] sound: INFO: possible recursive locking detected In-Reply-To: <20090109050621.GA16446@localhost> References: <20090108152037.GA25652@elte.hu> <20090109050621.GA16446@localhost> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 12766 Lines: 256 At Fri, 9 Jan 2009 13:06:21 +0800, Wu Fengguang wrote: > > On Thu, Jan 08, 2009 at 04:20:37PM +0100, Ingo Molnar wrote: > > > > FYI, -tip testing found this new lockdep workqueue locking assert > > triggered by the Intel HDA sound driver: > > > > [ 30.637612] alloc kstat_irqs on cpu 0 node 0 > > [ 30.647029] IOAPIC[0]: Set routing entry (2-22 -> 0x71 -> IRQ 22 Mode:1 Active:1) > > [ 30.654533] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > > [ 30.661782] HDA Intel 0000:00:1b.0: setting latency timer to 64 > > [ 30.667801] chipset global capabilities = 0x4401 > > [ 30.701090] codec_mask = 0x4 > > [ 30.701090] hda_intel: codec #2 probed OK > > [ 30.709090] hda-codec: No codec parser is available > > [ 30.714396] hda-intel: no codecs initialized > > [ 30.718689] > > [ 30.718689] ============================================= > > [ 30.718689] [ INFO: possible recursive locking detected ] > > [ 30.718689] 2.6.28-tip #2 > > [ 30.718689] --------------------------------------------- > > [ 30.718689] events/0/7 is trying to acquire lock: > > [ 30.718689] (events){--..}, at: [] flush_workqueue+0x0/0x90 > > [ 30.718689] > > [ 30.718689] but task is already holding lock: > > [ 30.718689] (events){--..}, at: [] run_workqueue+0x14a/0x240 > > [ 30.718689] > > [ 30.718689] other info that might help us debug this: > > [ 30.718689] 2 locks held by events/0/7: > > [ 30.718689] #0: (events){--..}, at: [] run_workqueue+0x14a/0x240 > > [ 30.718689] #1: (&wfc.work){--..}, at: [] run_workqueue+0x14a/0x240 > > I didn't see this bug, but ran into another one with linux-next 20090102: > > [ 844.111765] ALSA sound/pci/hda/hda_codec.c:882: hda_codec_cleanup_stream: NID=0x2 > [ 844.111915] > [ 844.111916] ======================================================= > [ 844.112018] [ INFO: possible circular locking dependency detected ] > [ 844.112076] 2.6.28-next-20090102 #33 > [ 844.112124] ------------------------------------------------------- > [ 844.112181] mplayer/3151 is trying to acquire lock: > [ 844.112235] (&pcm->open_mutex){--..}, at: [] snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112361] > [ 844.112362] but task is already holding lock: > [ 844.112458] (&mm->mmap_sem){----}, at: [] sys_munmap+0x42/0x80 > [ 844.112576] > [ 844.112577] which lock already depends on the new lock. > [ 844.112578] > [ 844.112712] > [ 844.112713] the existing dependency chain (in reverse order) is: > [ 844.112781] > [ 844.112781] -> #3 (&mm->mmap_sem){----}: > [ 844.112781] [] __lock_acquire+0x122b/0x1ae0 > [ 844.112781] [] lock_acquire+0x99/0xd0 > [ 844.112781] [] might_fault+0x73/0xa0 > [ 844.112781] [] snd_hda_mixer_amp_tlv+0x6d/0xf0 [snd_hda_codec] > [ 844.112781] [] alc_cap_vol_tlv+0x70/0xa0 [snd_hda_codec_realtek] > [ 844.112781] [] snd_ctl_tlv_ioctl+0x180/0x1b0 [snd] > [ 844.112781] [] snd_ctl_ioctl+0x927/0xf80 [snd] > [ 844.112781] [] vfs_ioctl+0x31/0xa0 > [ 844.112781] [] do_vfs_ioctl+0x76/0x4a0 > [ 844.112781] [] sys_ioctl+0x4a/0x80 > [ 844.112781] [] system_call_fastpath+0x16/0x1b > [ 844.112781] [] 0xffffffffffffffff > [ 844.112781] > [ 844.112781] -> #2 (&codec->spdif_mutex){--..}: > [ 844.112781] [] __lock_acquire+0x122b/0x1ae0 > [ 844.112781] [] lock_acquire+0x99/0xd0 > [ 844.112781] [] mutex_lock_nested+0xe8/0x370 > [ 844.112781] [] snd_hda_multi_out_dig_open+0x2b/0x60 [snd_hda_codec] > [ 844.112781] [] intel_hdmi_playback_pcm_open+0x49/0x60 [snd_hda_codec_intelhdmi] > [ 844.112781] [] azx_pcm_open+0x209/0x280 [snd_hda_intel] > [ 844.112781] [] snd_pcm_open_substream+0x58/0xd0 [snd_pcm] > [ 844.112781] [] snd_pcm_open+0x137/0x260 [snd_pcm] > [ 844.112781] [] snd_pcm_playback_open+0x2c/0x40 [snd_pcm] > [ 844.112781] [] snd_open+0x9e/0x180 [snd] > [ 844.112781] [] chrdev_open+0xe7/0x1d0 > [ 844.112781] [] __dentry_open+0xce/0x360 > [ 844.112781] [] nameidata_to_filp+0x57/0x70 > [ 844.112781] [] do_filp_open+0x20e/0x970 > [ 844.112781] [] do_sys_open+0x78/0x100 > [ 844.112781] [] sys_open+0x1b/0x20 > [ 844.112781] [] system_call_fastpath+0x16/0x1b > [ 844.112781] [] 0xffffffffffffffff > [ 844.112781] > [ 844.112781] -> #1 (&chip->open_mutex){--..}: > [ 844.112781] [] __lock_acquire+0x122b/0x1ae0 > [ 844.112781] [] lock_acquire+0x99/0xd0 > [ 844.112781] [] mutex_lock_nested+0xe8/0x370 > [ 844.112781] [] azx_pcm_open+0x48/0x280 [snd_hda_intel] > [ 844.112781] [] snd_pcm_open_substream+0x58/0xd0 [snd_pcm] > [ 844.112781] [] snd_pcm_open+0x137/0x260 [snd_pcm] > [ 844.112781] [] snd_pcm_playback_open+0x2c/0x40 [snd_pcm] > [ 844.112781] [] snd_open+0x9e/0x180 [snd] > [ 844.112781] [] chrdev_open+0xe7/0x1d0 > [ 844.112781] [] __dentry_open+0xce/0x360 > [ 844.112781] [] nameidata_to_filp+0x57/0x70 > [ 844.112781] [] do_filp_open+0x20e/0x970 > [ 844.112781] [] do_sys_open+0x78/0x100 > [ 844.112781] [] sys_open+0x1b/0x20 > [ 844.112781] [] system_call_fastpath+0x16/0x1b > [ 844.112781] [] 0xffffffffffffffff > [ 844.112781] > [ 844.112781] -> #0 (&pcm->open_mutex){--..}: > [ 844.112781] [] __lock_acquire+0x13ce/0x1ae0 > [ 844.112781] [] lock_acquire+0x99/0xd0 > [ 844.112781] [] mutex_lock_nested+0xe8/0x370 > [ 844.112781] [] snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112781] [] __fput+0xd5/0x230 > [ 844.112781] [] fput+0x1d/0x30 > [ 844.112781] [] remove_vma+0x4f/0x90 > [ 844.112781] [] do_munmap+0x342/0x390 > [ 844.112781] [] sys_munmap+0x50/0x80 > [ 844.112781] [] system_call_fastpath+0x16/0x1b > [ 844.112781] [] 0xffffffffffffffff > [ 844.112781] > [ 844.112781] other info that might help us debug this: > [ 844.112781] > [ 844.112781] 1 lock held by mplayer/3151: > [ 844.112781] #0: (&mm->mmap_sem){----}, at: [] sys_munmap+0x42/0x80 > [ 844.112781] > [ 844.112781] stack backtrace: > [ 844.112781] Pid: 3151, comm: mplayer Not tainted 2.6.28-next-20090102 #33 > [ 844.112781] Call Trace: > [ 844.112781] [] print_circular_bug_tail+0xe0/0xf0 > [ 844.112781] [] __lock_acquire+0x13ce/0x1ae0 > [ 844.112781] [] ? mark_held_locks+0x56/0xa0 > [ 844.112781] [] ? free_hot_cold_page+0x1b9/0x2e0 > [ 844.112781] [] ? trace_hardirqs_on+0xd/0x10 > [ 844.112781] [] lock_acquire+0x99/0xd0 > [ 844.112781] [] ? snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112781] [] mutex_lock_nested+0xe8/0x370 > [ 844.112781] [] ? snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112781] [] ? snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112781] [] snd_pcm_release+0x43/0xd0 [snd_pcm] > [ 844.112781] [] __fput+0xd5/0x230 > [ 844.112781] [] fput+0x1d/0x30 > [ 844.112781] [] remove_vma+0x4f/0x90 > [ 844.112781] [] do_munmap+0x342/0x390 > [ 844.112781] [] sys_munmap+0x50/0x80 > [ 844.112781] [] system_call_fastpath+0x16/0x1b > [ 844.119376] ALSA sound/pci/hda/hda_codec.c:882: hda_codec_cleanup_stream: NID=0x2 > > Which can be fixed by the following patch. This alone isn't enough. You need to replace all codec->spdif_mutex in the control get/put/info/tlv callbacks in hda_codec.c. Otherwise there is no meaning of the mutex. The mutex is to protect the rewrite of kcontrol->private_value dynamically. Could you fix and repost? thanks, Takashi > > Thanks, > Fengguang > --- > hda - fix lockdep warning > > ALSA sound/pci/hda/hda_codec.c:882: hda_codec_cleanup_stream: NID=0x2 > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.28-next-20090102 #33 > ------------------------------------------------------- > mplayer/3151 is trying to acquire lock: > (&pcm->open_mutex){--..}, at: [] snd_pcm_release+0x43/0xd0 [snd_pcm] > > but task is already holding lock: > (&mm->mmap_sem){----}, at: [] sys_munmap+0x42/0x80 > > which lock already depends on the new lock. > > Signed-off-by: Wu Fengguang > --- > sound/pci/hda/hda_codec.c | 1 + > sound/pci/hda/hda_codec.h | 1 + > sound/pci/hda/patch_realtek.c | 12 ++++++------ > 3 files changed, 8 insertions(+), 6 deletions(-) > > --- mm.orig/sound/pci/hda/hda_codec.c > +++ mm/sound/pci/hda/hda_codec.c > @@ -735,6 +735,7 @@ int /*__devinit*/ snd_hda_codec_new(stru > codec->bus = bus; > codec->addr = codec_addr; > mutex_init(&codec->spdif_mutex); > + mutex_init(&codec->control_mutex); > init_hda_cache(&codec->amp_cache, sizeof(struct hda_amp_info)); > init_hda_cache(&codec->cmd_cache, sizeof(struct hda_cache_head)); > snd_array_init(&codec->mixers, sizeof(struct snd_kcontrol *), 32); > --- mm.orig/sound/pci/hda/hda_codec.h > +++ mm/sound/pci/hda/hda_codec.h > @@ -771,6 +771,7 @@ struct hda_codec { > struct hda_cache_rec cmd_cache; /* cache for other commands */ > > struct mutex spdif_mutex; > + struct mutex control_mutex; > unsigned int spdif_status; /* IEC958 status bits */ > unsigned short spdif_ctls; /* SPDIF control bits */ > unsigned int spdif_in_enable; /* SPDIF input enable? */ > --- mm.orig/sound/pci/hda/patch_realtek.c > +++ mm/sound/pci/hda/patch_realtek.c > @@ -1502,11 +1502,11 @@ static int alc_cap_vol_info(struct snd_k > struct alc_spec *spec = codec->spec; > int err; > > - mutex_lock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_lock(&codec->control_mutex); > kcontrol->private_value = HDA_COMPOSE_AMP_VAL(spec->adc_nids[0], 3, 0, > HDA_INPUT); > err = snd_hda_mixer_amp_volume_info(kcontrol, uinfo); > - mutex_unlock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_unlock(&codec->control_mutex); > return err; > } > > @@ -1517,11 +1517,11 @@ static int alc_cap_vol_tlv(struct snd_kc > struct alc_spec *spec = codec->spec; > int err; > > - mutex_lock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_lock(&codec->control_mutex); > kcontrol->private_value = HDA_COMPOSE_AMP_VAL(spec->adc_nids[0], 3, 0, > HDA_INPUT); > err = snd_hda_mixer_amp_tlv(kcontrol, op_flag, size, tlv); > - mutex_unlock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_unlock(&codec->control_mutex); > return err; > } > > @@ -1537,11 +1537,11 @@ static int alc_cap_getput_caller(struct > unsigned int adc_idx = snd_ctl_get_ioffidx(kcontrol, &ucontrol->id); > int err; > > - mutex_lock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_lock(&codec->control_mutex); > kcontrol->private_value = HDA_COMPOSE_AMP_VAL(spec->adc_nids[adc_idx], > 3, 0, HDA_INPUT); > err = func(kcontrol, ucontrol); > - mutex_unlock(&codec->spdif_mutex); /* reuse spdif_mutex */ > + mutex_unlock(&codec->control_mutex); > return err; > } > > -- 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/