lkml.org 
[lkml]   [2012]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bluetooth: fix deadlock on device reset and power down
Am 02.04.2012 11:03, schrieb Andrei Emeltchenko:
> Hi guys,
>
> On Mon, Apr 02, 2012 at 10:44:43AM +0200, David Herrmann wrote:
>> Hi Andrei and Alexander
>>
>> On Mon, Apr 2, 2012 at 10:29 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>>> 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.
>>
>> hci_conn_timeout does lock the device. See the source. But the problem
>
> I think you need to check commit e72acc13c770a82b4ce4a07e9716f29320eae0f8
>
> commit e72acc13c770a82b4ce4a07e9716f29320eae0f8
> Author: Andre Guedes <andre.guedes@openbossa.org>
> Date: Fri Jan 27 19:42:03 2012 -0300
>
> Bluetooth: Remove unneeded locking
>
> We don't need locking hdev in hci_conn_timeout() since it doesn't
> access any hdev's shared resources, it basically queues HCI commands.

So if the locks in hci_conn_timeout() aren't needed, your commit which
removes them should go to the stable tree because it fixes a painful
deadlock.

Regards,

Alexander



\
 
 \ /
  Last update: 2012-04-02 11:19    [W:0.039 / U:0.848 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site