mbox series

[v2,0/4] Cancel sync commands if a TX failure occurs

Message ID 20211203145902.3223861-1-benjamin@sipsolutions.net (mailing list archive)
Headers show
Series Cancel sync commands if a TX failure occurs | expand

Message

Benjamin Berg Dec. 3, 2021, 2:58 p.m. UTC 
It was reported that userspace could hang for 10s after resuming due to
btusb hitting the internal timeout when sending the firmware.

In this case, the bluetooth dongle disappeared right after resume due to
the thinkpad_acpi rfkill being blocked. This causes the USB device to
disappear, however the bluetooth stack does not handle the
corresponding ENODEV errors and instead waits for a timeout to happen.

To avoid blocking everything for such a long time, the synchronous
command has to finish immediately after an ENODEV error occurs. This
requires further error handling, which this patchset adds by building
on top of the existing cancellation infrastructure for synchronous
commands.

Note that this just adds basic error handling in order to quickly abort
the initialization routine in case the device disappears at that time.
Additional error handling such as calling hci_reset_dev might be
sensible in some cases.

Benjamin Berg (4):
  Bluetooth: Reset more state when cancelling a sync command
  Bluetooth: Add hci_cmd_sync_cancel to public API
  Bluetooth: hci_core: Cancel sync command if sending a frame failed
  Bluetooth: btusb: Cancel sync commands for certain URB errors

 drivers/bluetooth/btusb.c        | 11 +++++++++--
 include/net/bluetooth/hci_sync.h |  1 +
 net/bluetooth/hci_core.c         | 14 +++++++++++---
 net/bluetooth/hci_request.c      | 13 +------------
 net/bluetooth/hci_request.h      |  1 -
 net/bluetooth/hci_sync.c         | 17 +++++++++++++++++
 6 files changed, 39 insertions(+), 18 deletions(-)

Comments

Luiz Augusto von Dentz Dec. 3, 2021, 6:47 p.m. UTC | #1 
Hi Benjamin,

On Fri, Dec 3, 2021 at 6:59 AM Benjamin Berg <benjamin@sipsolutions.net> wrote:
>
> It was reported that userspace could hang for 10s after resuming due to
> btusb hitting the internal timeout when sending the firmware.
>
> In this case, the bluetooth dongle disappeared right after resume due to
> the thinkpad_acpi rfkill being blocked. This causes the USB device to
> disappear, however the bluetooth stack does not handle the
> corresponding ENODEV errors and instead waits for a timeout to happen.
>
> To avoid blocking everything for such a long time, the synchronous
> command has to finish immediately after an ENODEV error occurs. This
> requires further error handling, which this patchset adds by building
> on top of the existing cancellation infrastructure for synchronous
> commands.
>
> Note that this just adds basic error handling in order to quickly abort
> the initialization routine in case the device disappears at that time.
> Additional error handling such as calling hci_reset_dev might be
> sensible in some cases.
>
> Benjamin Berg (4):
>   Bluetooth: Reset more state when cancelling a sync command
>   Bluetooth: Add hci_cmd_sync_cancel to public API
>   Bluetooth: hci_core: Cancel sync command if sending a frame failed
>   Bluetooth: btusb: Cancel sync commands for certain URB errors
>
>  drivers/bluetooth/btusb.c        | 11 +++++++++--
>  include/net/bluetooth/hci_sync.h |  1 +
>  net/bluetooth/hci_core.c         | 14 +++++++++++---
>  net/bluetooth/hci_request.c      | 13 +------------
>  net/bluetooth/hci_request.h      |  1 -
>  net/bluetooth/hci_sync.c         | 17 +++++++++++++++++
>  6 files changed, 39 insertions(+), 18 deletions(-)
>
> --
> 2.33.1

Applied, thanks.