Re: BUG: possible deadlock detected! (sound) [Was: 2.6.17-rc5-mm1]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux