aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/storage/realtek_cr.c
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2019-04-19 13:52:38 -0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-04-19 15:15:13 -0400
commitc2b71462d294cf517a0bc6e4fd6424d7cee5596f (patch)
treedf8fc206e13f52f2c4b174002ef42f2e9b51996f /drivers/usb/storage/realtek_cr.c
parentfc834e607ae3d18e1a20bca3f9a2d7f52ea7a2be (diff)
USB: core: Fix bug caused by duplicate interface PM usage counter
The syzkaller fuzzer reported a bug in the USB hub driver which turned out to be caused by a negative runtime-PM usage counter. This allowed a hub to be runtime suspended at a time when the driver did not expect it. The symptom is a WARNING issued because the hub's status URB is submitted while it is already active: URB 0000000031fb463e submitted while active WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 The negative runtime-PM usage count was caused by an unfortunate design decision made when runtime PM was first implemented for USB. At that time, USB class drivers were allowed to unbind from their interfaces without balancing the usage counter (i.e., leaving it with a positive count). The core code would take care of setting the counter back to 0 before allowing another driver to bind to the interface. Later on when runtime PM was implemented for the entire kernel, the opposite decision was made: Drivers were required to balance their runtime-PM get and put calls. In order to maintain backward compatibility, however, the USB subsystem adapted to the new implementation by keeping an independent usage counter for each interface and using it to automatically adjust the normal usage counter back to 0 whenever a driver was unbound. This approach involves duplicating information, but what is worse, it doesn't work properly in cases where a USB class driver delays decrementing the usage counter until after the driver's disconnect() routine has returned and the counter has been adjusted back to 0. Doing so would cause the usage counter to become negative. There's even a warning about this in the USB power management documentation! As it happens, this is exactly what the hub driver does. The kick_hub_wq() routine increments the runtime-PM usage counter, and the corresponding decrement is carried out by hub_event() in the context of the hub_wq work-queue thread. This work routine may sometimes run after the driver has been unbound from its interface, and when it does it causes the usage counter to go negative. It is not possible for hub_disconnect() to wait for a pending hub_event() call to finish, because hub_disconnect() is called with the device lock held and hub_event() acquires that lock. The only feasible fix is to reverse the original design decision: remove the duplicate interface-specific usage counter and require USB drivers to balance their runtime PM gets and puts. As far as I know, all existing drivers currently do this. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/storage/realtek_cr.c')
-rw-r--r--drivers/usb/storage/realtek_cr.c13
1 files changed, 5 insertions, 8 deletions
diff --git a/drivers/usb/storage/realtek_cr.c b/drivers/usb/storage/realtek_cr.c
index 31b024441938..cc794e25a0b6 100644
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -763,18 +763,16 @@ static void rts51x_suspend_timer_fn(struct timer_list *t)
763 break; 763 break;
764 case RTS51X_STAT_IDLE: 764 case RTS51X_STAT_IDLE:
765 case RTS51X_STAT_SS: 765 case RTS51X_STAT_SS:
766 usb_stor_dbg(us, "RTS51X_STAT_SS, intf->pm_usage_cnt:%d, power.usage:%d\n", 766 usb_stor_dbg(us, "RTS51X_STAT_SS, power.usage:%d\n",
767 atomic_read(&us->pusb_intf->pm_usage_cnt),
768 atomic_read(&us->pusb_intf->dev.power.usage_count)); 767 atomic_read(&us->pusb_intf->dev.power.usage_count));
769 768
770 if (atomic_read(&us->pusb_intf->pm_usage_cnt) > 0) { 769 if (atomic_read(&us->pusb_intf->dev.power.usage_count) > 0) {
771 usb_stor_dbg(us, "Ready to enter SS state\n"); 770 usb_stor_dbg(us, "Ready to enter SS state\n");
772 rts51x_set_stat(chip, RTS51X_STAT_SS); 771 rts51x_set_stat(chip, RTS51X_STAT_SS);
773 /* ignore mass storage interface's children */ 772 /* ignore mass storage interface's children */
774 pm_suspend_ignore_children(&us->pusb_intf->dev, true); 773 pm_suspend_ignore_children(&us->pusb_intf->dev, true);
775 usb_autopm_put_interface_async(us->pusb_intf); 774 usb_autopm_put_interface_async(us->pusb_intf);
776 usb_stor_dbg(us, "RTS51X_STAT_SS 01, intf->pm_usage_cnt:%d, power.usage:%d\n", 775 usb_stor_dbg(us, "RTS51X_STAT_SS 01, power.usage:%d\n",
777 atomic_read(&us->pusb_intf->pm_usage_cnt),
778 atomic_read(&us->pusb_intf->dev.power.usage_count)); 776 atomic_read(&us->pusb_intf->dev.power.usage_count));
779 } 777 }
780 break; 778 break;
@@ -807,11 +805,10 @@ static void rts51x_invoke_transport(struct scsi_cmnd *srb, struct us_data *us)
807 int ret; 805 int ret;
808 806
809 if (working_scsi(srb)) { 807 if (working_scsi(srb)) {
810 usb_stor_dbg(us, "working scsi, intf->pm_usage_cnt:%d, power.usage:%d\n", 808 usb_stor_dbg(us, "working scsi, power.usage:%d\n",
811 atomic_read(&us->pusb_intf->pm_usage_cnt),
812 atomic_read(&us->pusb_intf->dev.power.usage_count)); 809 atomic_read(&us->pusb_intf->dev.power.usage_count));
813 810
814 if (atomic_read(&us->pusb_intf->pm_usage_cnt) <= 0) { 811 if (atomic_read(&us->pusb_intf->dev.power.usage_count) <= 0) {
815 ret = usb_autopm_get_interface(us->pusb_intf); 812 ret = usb_autopm_get_interface(us->pusb_intf);
816 usb_stor_dbg(us, "working scsi, ret=%d\n", ret); 813 usb_stor_dbg(us, "working scsi, ret=%d\n", ret);
817 } 814 }