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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Oliver,

> > > > > 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.
> 
> OK.
> 
> > 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.
> 
> But won't the module be marked as going away and make try_module_get()
> fail?

when calling "hciconfig hci0 up" then it is impossible to unload the
btusb module since we keep a module reference.

I am thinking that just __set_isoc_interface(..., 0) when disconnect
gets called for the isoc interface and the releasing the interface is
the more cleaner way. I have to think about this.

Regards

Marcel