Re: [patch]race condition in btusb disconnect() handling

Hi Oliver,

quoted

quoted

First you release the interface, then you unregister the hci.

Putting it after hci_unregister_dev is an issue. The unregister will
call __hci_dev_put and then in return will call the destruct callback
which will free the data pointer.

So either we use hci_dev_hold or make sure that disconnect can only
disable the SCO interface. That comes directly with the first comment
from you.

Here is a new version. I am afraid normal hci_dev_hold would fail if
the disconnect happens because the btusb module is being unloaded.

the btusb_stop_traffic change is bogus. You don't need that. The flush
callback will be called to ensure that all TX traffic is released.

I am not sure about hci_dev_hold. We ensure that a reference count to
the module is hold when the HCI device is brought up.

Regards

Marcel