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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
