linux-kernel - Re: [PATCH 2/2] bluetooth: raise HCI_CMD

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]

Message-ID: <5384AD17.3020608@ahsoftware.de>
Date:	Tue, 27 May 2014 17:19:51 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Luiz Augusto von Dentz <luiz.dentz@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Gustavo Padovan <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>
Subject: Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s

Am 16.05.2014 07:35, schrieb Alexander Holler:
> Am 15.05.2014 17:19, schrieb Alexander Holler:
>> Am 15.05.2014 16:50, schrieb Alexander Holler:
>>> Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
>>
>>>> This timeout seems arbitrary so I suppose we can increase it if we
>>>> feel it is necessary but we used already different timeout for
>>>> different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
>>>> identify which command is more likely to timeout.
>>>>
>>>> We could perhaps auto reset if a command timeout if there is really no
>>>> other way to recover.
>>>
>>> It is arbitrary but 2s is not enough here. And as I've written in the
>>> description, there is absolutely no reason to keep this timeout
>>> unnecessarily short. No one cares if an error message appears after 2s
>>> or 8s if the communication with the dongle is in both cases broken
>>> afterwards.
>>>
>>> One of the commands I experieced the problem with was e.g.
>>> HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE.
>>
>> The problem is that you can never be sure what the origin of a timeouted
>> command was. It might have been e.g. the USB-subsystem through wich the
>> command and the response has to travel (in case of USB dongles) and not
>> the dongle itself.
>
> To explain a bit more, the box I'm experiencing these problems boots
> from USB2.0 HD. So it's likely that there is quiet some action on the
> bus and that shouldn't affect the operation of the BT-stack (besides
> slowing it maybe a bit down).

Anything wrong with my conclusion?

I don't know what's the origin of the current timeout of 2s, but I don't 
think it takes the used transport into account.

So if the source of these 2s is the spec for BT-devices, the 2s would 
make sense as a timeout to test BT-devices, but it already becomes an 
arbitrary value whenever the transport isn't realtime and/or exclusive 
for the device but e.g. an I/O scheduler is inbetween (which is the case 
for USB).

Regards,

Alexander Holler
--
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/