diff mbox series

[v6,3/3] USB: Fix device driver race

Message ID 20200727104644.149873-3-hadess@hadess.net (mailing list archive)
State New, archived
Headers show
Series [v6,1/3] USB: Simplify USB ID table match | expand

Commit Message

Bastien Nocera July 27, 2020, 10:46 a.m. UTC
When a new device with a specialised device driver is plugged in, the
new driver will be modprobe()'d but the driver core will attach the
"generic" driver to the device.

After that, nothing will trigger a reprobe when the modprobe()'d device
driver has finished initialising, as the device has the "generic"
driver attached to it.

Trigger a reprobe ourselves when new specialised drivers get registered.

Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available")
Signed-off-by: Bastien Nocera <hadess@hadess.net>
---
Changes since v5:
- Throw error when device_reprobe() fails

Changes since v4:
- Add commit subject to "fixes" section
- Clarify conditional that checks for generic driver
- Remove check duplicated inside the loop

Changes since v3:
- Only reprobe devices that could use the new driver
- Many code fixes

Changes since v2:
- Fix formatting

Changes since v1:
- Simplified after Alan Stern's comments and some clarifications from
Benjamin Tissoires.

 drivers/usb/core/driver.c | 40 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

Comments

Bastien Nocera Aug. 3, 2020, 3:04 p.m. UTC | #1
On Mon, 2020-07-27 at 12:46 +0200, Bastien Nocera wrote:
> When a new device with a specialised device driver is plugged in, the
> new driver will be modprobe()'d but the driver core will attach the
> "generic" driver to the device.
> 
> After that, nothing will trigger a reprobe when the modprobe()'d
> device
> driver has finished initialising, as the device has the "generic"
> driver attached to it.
> 
> Trigger a reprobe ourselves when new specialised drivers get
> registered.
> 
> Fixes: 88b7381a939d ("USB: Select better matching USB drivers when
> available")
> Signed-off-by: Bastien Nocera <hadess@hadess.net>

Greg, Alan, are you happy with this iteration?

If so, I can send it again with Alan's acks, along with a fix for the
function name Alan mentioned. I see that the first patch in the list
landed in usb-next already.
Greg Kroah-Hartman Aug. 3, 2020, 3:38 p.m. UTC | #2
On Mon, Aug 03, 2020 at 05:04:46PM +0200, Bastien Nocera wrote:
> On Mon, 2020-07-27 at 12:46 +0200, Bastien Nocera wrote:
> > When a new device with a specialised device driver is plugged in, the
> > new driver will be modprobe()'d but the driver core will attach the
> > "generic" driver to the device.
> > 
> > After that, nothing will trigger a reprobe when the modprobe()'d
> > device
> > driver has finished initialising, as the device has the "generic"
> > driver attached to it.
> > 
> > Trigger a reprobe ourselves when new specialised drivers get
> > registered.
> > 
> > Fixes: 88b7381a939d ("USB: Select better matching USB drivers when
> > available")
> > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> 
> Greg, Alan, are you happy with this iteration?
> 
> If so, I can send it again with Alan's acks, along with a fix for the
> function name Alan mentioned. I see that the first patch in the list
> landed in usb-next already.
> 

Yes, please resend the remaining patches.  I don't recall seeing Alan's
ack on it.

thanks,

greg k-h
Alan Stern Aug. 3, 2020, 4:02 p.m. UTC | #3
On Mon, Aug 03, 2020 at 05:04:46PM +0200, Bastien Nocera wrote:
> On Mon, 2020-07-27 at 12:46 +0200, Bastien Nocera wrote:
> > When a new device with a specialised device driver is plugged in, the
> > new driver will be modprobe()'d but the driver core will attach the
> > "generic" driver to the device.
> > 
> > After that, nothing will trigger a reprobe when the modprobe()'d
> > device
> > driver has finished initialising, as the device has the "generic"
> > driver attached to it.
> > 
> > Trigger a reprobe ourselves when new specialised drivers get
> > registered.
> > 
> > Fixes: 88b7381a939d ("USB: Select better matching USB drivers when
> > available")
> > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> 
> Greg, Alan, are you happy with this iteration?
> 
> If so, I can send it again with Alan's acks, along with a fix for the
> function name Alan mentioned. I see that the first patch in the list
> landed in usb-next already.

This is almost the same as v5, which I already Acked.  The only 
difference is the error logging when the reprobe fails, and that looks 
fine.  So...

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern
Bastien Nocera Aug. 4, 2020, 11:41 a.m. UTC | #4
On Mon, 2020-08-03 at 17:38 +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 03, 2020 at 05:04:46PM +0200, Bastien Nocera wrote:
> > On Mon, 2020-07-27 at 12:46 +0200, Bastien Nocera wrote:
> > > When a new device with a specialised device driver is plugged in,
> > > the
> > > new driver will be modprobe()'d but the driver core will attach
> > > the
> > > "generic" driver to the device.
> > > 
> > > After that, nothing will trigger a reprobe when the modprobe()'d
> > > device
> > > driver has finished initialising, as the device has the "generic"
> > > driver attached to it.
> > > 
> > > Trigger a reprobe ourselves when new specialised drivers get
> > > registered.
> > > 
> > > Fixes: 88b7381a939d ("USB: Select better matching USB drivers
> > > when
> > > available")
> > > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > 
> > Greg, Alan, are you happy with this iteration?
> > 
> > If so, I can send it again with Alan's acks, along with a fix for
> > the
> > function name Alan mentioned. I see that the first patch in the
> > list
> > landed in usb-next already.
> > 
> 
> Yes, please resend the remaining patches.  I don't recall seeing
> Alan's
> ack on it.

Resent as v7. There's a new patch in the lot, based on a comment by
Alan in this thread which I thought appropriate to include.

Cheers
Greg Kroah-Hartman Aug. 4, 2020, 11:56 a.m. UTC | #5
On Tue, Aug 04, 2020 at 01:41:25PM +0200, Bastien Nocera wrote:
> On Mon, 2020-08-03 at 17:38 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Aug 03, 2020 at 05:04:46PM +0200, Bastien Nocera wrote:
> > > On Mon, 2020-07-27 at 12:46 +0200, Bastien Nocera wrote:
> > > > When a new device with a specialised device driver is plugged in,
> > > > the
> > > > new driver will be modprobe()'d but the driver core will attach
> > > > the
> > > > "generic" driver to the device.
> > > > 
> > > > After that, nothing will trigger a reprobe when the modprobe()'d
> > > > device
> > > > driver has finished initialising, as the device has the "generic"
> > > > driver attached to it.
> > > > 
> > > > Trigger a reprobe ourselves when new specialised drivers get
> > > > registered.
> > > > 
> > > > Fixes: 88b7381a939d ("USB: Select better matching USB drivers
> > > > when
> > > > available")
> > > > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > > 
> > > Greg, Alan, are you happy with this iteration?
> > > 
> > > If so, I can send it again with Alan's acks, along with a fix for
> > > the
> > > function name Alan mentioned. I see that the first patch in the
> > > list
> > > landed in usb-next already.
> > > 
> > 
> > Yes, please resend the remaining patches.  I don't recall seeing
> > Alan's
> > ack on it.
> 
> Resent as v7. There's a new patch in the lot, based on a comment by
> Alan in this thread which I thought appropriate to include.

Thanks, will look at them once 5.9-rc1 is out as I can't do anything
with my tree until then.

greg k-h
diff mbox series

Patch

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index f81606c6a35b..7e73e989645b 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -905,6 +905,35 @@  static int usb_uevent(struct device *dev, struct kobj_uevent_env *env)
 	return 0;
 }
 
+static bool is_dev_usb_generic_driver(struct device *dev)
+{
+	struct usb_device_driver *udd = dev->driver ?
+		to_usb_device_driver(dev->driver) : NULL;
+
+	return udd == &usb_generic_driver;
+}
+
+static int __usb_bus_reprobe_drivers(struct device *dev, void *data)
+{
+	struct usb_device_driver *new_udriver = data;
+	struct usb_device *udev;
+	int ret;
+
+	if (!is_dev_usb_generic_driver(dev))
+		return 0;
+
+	udev = to_usb_device(dev);
+	if (usb_device_match_id(udev, new_udriver->id_table) == NULL &&
+	    (!new_udriver->match || new_udriver->match(udev) != 0))
+		return 0;
+
+	ret = device_reprobe(dev);
+	if (ret && ret != -EPROBE_DEFER)
+		dev_err(dev, "Failed to reprobe device (error %d)\n", ret);
+
+	return 0;
+}
+
 /**
  * usb_register_device_driver - register a USB device (not interface) driver
  * @new_udriver: USB operations for the device driver
@@ -934,13 +963,20 @@  int usb_register_device_driver(struct usb_device_driver *new_udriver,
 
 	retval = driver_register(&new_udriver->drvwrap.driver);
 
-	if (!retval)
+	if (!retval) {
 		pr_info("%s: registered new device driver %s\n",
 			usbcore_name, new_udriver->name);
-	else
+		/*
+		 * Check whether any device could be better served with
+		 * this new driver
+		 */
+		bus_for_each_dev(&usb_bus_type, NULL, new_udriver,
+				 __usb_bus_reprobe_drivers);
+	} else {
 		printk(KERN_ERR "%s: error %d registering device "
 			"	driver %s\n",
 			usbcore_name, retval, new_udriver->name);
+	}
 
 	return retval;
 }