linux-kernel - Re: bluetooth: fix deadlock on device reset and power down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 02 Apr 2012 12:16:32 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Andrei Emeltchenko <andrei.emeltchenko.news@...il.com>
CC:	David Herrmann <dh.herrmann@...glemail.com>,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Gustavo F. Padovan" <padovan@...fusion.mobi>,
	stable@...r.kernel.org, Andre Guedes <andre.guedes@...nbossa.org>
Subject: Re: bluetooth: fix deadlock on device reset and power down

Am 02.04.2012 11:17, schrieb Alexander Holler:
> 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@...oftware.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@...nbossa.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.

Oh, sorry, that patch is not from you, your first name is only similiar. 
I've added the author to cc, just in case the lock might still be needed 
in 3.3 if no other patches (from 3.4) besides that one are applied.

Regards,

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