On Sun, Feb 18, 2024 at 12:54:36AM +0100, Michal Pecio wrote: > A call to usb_set_interface() crashes if the device is deallocated > concurrently, such as due to physical removal or serious IO error. > It could also interfere with other drivers using the device if the > current driver is unbound before the call is done. > > Document the need to delay driver unbinding until this call returns, > which solves both issues. > > Explicitly mention finishing pending operations in the documentation > of the driver disconnect callback. > > Signed-off-by: Michal Pecio <michal.pecio@xxxxxxxxx> > --- Reviewed-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > Documentation/driver-api/usb/callbacks.rst | 4 +++- > drivers/usb/core/message.c | 3 ++- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/driver-api/usb/callbacks.rst b/Documentation/driver-api/usb/callbacks.rst > index 2b80cf54bcc3..c7fa55375e9a 100644 > --- a/Documentation/driver-api/usb/callbacks.rst > +++ b/Documentation/driver-api/usb/callbacks.rst > @@ -100,7 +100,9 @@ This callback is a signal to break any connection with an interface. > You are not allowed any IO to a device after returning from this > callback. You also may not do any other operation that may interfere > with another driver bound the interface, eg. a power management > -operation. > +operation. Outstanding operations on the device must complete or be > +aborted before this callback returns. > + > If you are called due to a physical disconnection, all your URBs will be > killed by usbcore. Note that in this case disconnect will be called some > time after the physical disconnection. Thus your driver must be prepared > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c > index 077dfe48d01c..08acebd51823 100644 > --- a/drivers/usb/core/message.c > +++ b/drivers/usb/core/message.c > @@ -1516,7 +1516,8 @@ void usb_enable_interface(struct usb_device *dev, > * This call is synchronous, and may not be used in an interrupt context. > * Also, drivers must not change altsettings while urbs are scheduled for > * endpoints in that interface; all such urbs must first be completed > - * (perhaps forced by unlinking). > + * (perhaps forced by unlinking). If a thread in your driver uses this call, > + * make sure your disconnect() method can wait for it to complete. > * > * Return: Zero on success, or else the status code returned by the > * underlying usb_control_msg() call. > -- > 2.43.0
