Am 02.04.2012 08:55, schrieb Andrei Emeltchenko: > Hi Alexander, > > On Sat, Mar 31, 2012 at 03:23:38PM +0200, Alexander Holler wrote: >> I've experienced a deadlock on shutdown using kernel 3.3 and tracked >> it down. Because I'm not very familiar with the bluetooth stack I'm >> not sure if the below patch is correct, but it fixed the problem >> here. > > Could you please attach deadlock dump? > >> >> Commit 09fd0de5bd8f8ef3317e5365f92f1a13dcd89aa9 introduced a deadlock: >> >> bluetoothd calls ioctl HCIDEVDOWN >> hci_sock_ioctl() >> hci_dev_close() >> hci_dev_do_close() >> hci_dev_lock(hdev); >> inquiry_cache_flush(); >> hci_conn_hash_flush(); >> hci_conn_del() >> cancel_delayed_work_sync() >> hci_conn_timeout() >> hci_dev_lock(hdev); /* DEADLOCK */ > > I am actually not sure that hci_conn_timeout locks hdev. Why do you think > so? By reading the source, printk and suffering through the deadlock. It's especially painfull when using a bt-keyboard and systemd, because systemd tries 4 times (~ some minutes) to kill bluetoothd before it marks the service as failed and finally continues to shut down. Just try to kill bluetoothd while a bt-mouse or bt-keyboard is connected. But I have to admit, that my patch is likely the wrong solution as I think it will introduce some race conditions. Anyway, I prefer to live with them (the race conditions) instead of the deadlock. So for inclusion into the kernel a proper solution is needed. But already said, I'm not familiar with the bt-stack and don't know about the locking strategies inside the stack, so it's hard for me to find my way through the source. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html