Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751494AbWE3MoV@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751494AbWE3MoV (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 30 May 2006 08:44:21 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751490AbWE3MoV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 May 2006 08:44:21 -0400
Received: from ns2.suse.de ([195.135.220.15]:30634 "EHLO mx2.suse.de")
	by vger.kernel.org with ESMTP id S1751495AbWE3MoV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 May 2006 08:44:21 -0400
Date: Tue, 30 May 2006 14:44:05 +0200
Message-ID: <s5h3berd6ne.wl%tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Jiri Slaby <jirislaby@gmail.com>, Andrew Morton <akpm@osdl.org>,
       linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
       emu10k1-devel@lists.sourceforge.net, James@superbug.demon.co.uk,
       perex@suse.cz
Subject: Re: BUG: possible deadlock detected! (sound) [Was: 2.6.17-rc5-mm1]
In-Reply-To: <1148987188.3636.52.camel@laptopd505.fenrus.org>
References: <20060530022925.8a67b613.akpm@osdl.org>
	<447C22CE.2060402@gmail.com>
	<1148987188.3636.52.camel@laptopd505.fenrus.org>
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 MULE XEmacs/21.5 (beta25)
 (eggplant) (+CVS-20060326) (i386-suse-linux)
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
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2245
Lines: 60

At Tue, 30 May 2006 13:06:28 +0200,
Arjan van de Ven wrote:
> 
> On Tue, 2006-05-30 at 147 +0159, Jiri Slaby wrote:
> 
> (I've turned your backtrace upside down to show it "chronological")
> 
>  [<c05911e0>] alsa_emu10k1_synth_init+0x22/0x24
>  [<c0333d04>] snd_seq_device_register_driver+0x8f/0xeb
> 
> this one does:
> 
>        mutex_lock(&ops->reg_mutex);
>        ...
>        list_for_each(head, &ops->dev_list) {
>                 struct snd_seq_device *dev = list_entry(head, struct snd_seq_device, list);
>                 init_device(dev, ops);
>        }
>        mutex_unlock(&ops->reg_mutex);
> 
>  [<c0333537>] init_device+0x2c/0x94
>   which calls into the driver
>  [<c0352c39>] snd_emu10k1_synth_new_device+0xe7/0x14e
>  [<c0353f50>] snd_emux_register+0x10d/0x13f
>  [<c0358260>] snd_emux_init_seq_oss+0x35/0x9c
>  [<c0333aa0>] snd_seq_device_new+0x96/0x111
> 
> and this one does
>         mutex_lock(&ops->reg_mutex);
>         list_add_tail(&dev->list, &ops->dev_list);
>         ops->num_devices++;
>         mutex_unlock(&ops->reg_mutex);
> 
> 
> so... on first sight this looks like a real deadlock;
> unless the ALSA folks can tell me why "ops" is always different,
> and what the lock ordering rules between those is...

This ops is a unique object assigned to a different "id" string.

The first snd_seq_device_register_driver() called from emu10k1_synth.c
is the registration for the id "snd-synth-emu10k1".
Then in init_device(), the corresponding devices are initialized, and
one callback registers again another device for OSS sequencer with a
different id "snd-seq-oss" via snd_seq_device_new() inside the lock.
Now it hits the lock-detector but the lock should belong to a
different ops object in practice.

This nested lock may happen only in two drivers, emu10k1-synth and
opl3, and only together with OSS emulation.  Since the OSS emulation
layer don't do active registration from itself, no deadlock should
happen (in theory -- I may oversee something :)


Takashi
-
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/