https://bugzilla.kernel.org/show_bug.cgi?id=198043 --- Comment #2 from luc (l.perneel@xxxxxxxxxxx) --- OK found the cause, but it is solved in the upcoming 4.15 kernel. Patch can be found in: https://patchwork.kernel.org/patch/9963977/ In short: the function hci_send_monitor_ctrl_event (in hci_sock.c) takes the read_lock. Then it calls hci_send_to_channel which also takes the read_lock. If now between the two read lock takes, a write lock is entered on another cpu (and thus the waiting writer flag is set), the second take will decrease again its counter (not entering the lock) and wait until the writer finished. However, as the same thread took it already, it will never decrease to zero. At the end both cpus are spinlocking waiting on each other for ever. On a dual core system, this actually means you are dead. (in fact you loose two cores when this happen on whatever system, and each next bluetooth request can lockup another core until the system is dead). I will fix my 4.9 kernel, but I hope this nasty bug is backported towards older kernels. -- You are receiving this mail because: You are the assignee for the bug.-- 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
