[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230105230119.2.I16b51f32db0c32f8a8532900bfe1c70c8572881a@changeid>
Date: Thu, 5 Jan 2023 23:03:29 +0000
From: Matthias Kaehlcke <mka@...omium.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Johan Hovold <johan@...nel.org>, linux-usb@...r.kernel.org,
Stefan Wahren <stefan.wahren@...e.com>,
Alexander Stein <alexander.stein@...tq-group.com>,
Icenowy Zheng <uwu@...nowy.me>,
Douglas Anderson <dianders@...omium.org>,
stable@...r.kernel.org, linux-kernel@...r.kernel.org,
Matthias Kaehlcke <mka@...omium.org>,
Ravi Chandra Sadineni <ravisadineni@...omium.org>
Subject: [PATCH 2/2] usb: misc: onboard_hub: Move 'attach' work to the driver
Currently each onboard_hub platform device owns an 'attach' work,
which is scheduled when the device probes. With this deadlocks
have been reported on a Raspberry Pi 3 B+ [1], which has nested
onboard hubs.
The flow of the deadlock is something like this (with the onboard_hub
driver built as a module) [2]:
- USB root hub is instantiated
- core hub driver calls onboard_hub_create_pdevs(), which creates the
'raw' platform device for the 1st level hub
- 1st level hub is probed by the core hub driver
- core hub driver calls onboard_hub_create_pdevs(), which creates
the 'raw' platform device for the 2nd level hub
- onboard_hub platform driver is registered
- platform device for 1st level hub is probed
- schedules 'attach' work
- platform device for 2nd level hub is probed
- schedules 'attach' work
- onboard_hub USB driver is registered
- device (and parent) lock of hub is held while the device is
re-probed with the onboard_hub driver
- 'attach' work (running in another thread) calls driver_attach(), which
blocks on one of the hub device locks
- onboard_hub_destroy_pdevs() is called by the core hub driver when one
of the hubs is detached
- destroying the pdevs invokes onboard_hub_remove(), which waits for the
'attach' work to complete
- waits forever, since the 'attach' work can't acquire the device lock
Use a single work struct for the driver instead of having a work struct
per onboard hub platform driver instance. With that it isn't necessary
to cancel the work in onboard_hub_remove(), which fixes the deadlock.
The work is only cancelled when the driver is unloaded.
[1] https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/
[2] https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/
Cc: stable@...r.kernel.org
Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver")
Link: https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/
Link: https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/
Reported-by: Stefan Wahren <stefan.wahren@...e.com>
Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
---
drivers/usb/misc/onboard_usb_hub.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c
index db0844b30bbd..8bc4deb465f0 100644
--- a/drivers/usb/misc/onboard_usb_hub.c
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -27,7 +27,10 @@
#include "onboard_usb_hub.h"
+static void onboard_hub_attach_usb_driver(struct work_struct *work);
+
static struct usb_device_driver onboard_hub_usbdev_driver;
+static DECLARE_WORK(attach_usb_driver_work, onboard_hub_attach_usb_driver);
/************************** Platform driver **************************/
@@ -45,7 +48,6 @@ struct onboard_hub {
bool is_powered_on;
bool going_away;
struct list_head udev_list;
- struct work_struct attach_usb_driver_work;
struct mutex lock;
};
@@ -270,9 +272,15 @@ static int onboard_hub_probe(struct platform_device *pdev)
*
* This needs to be done deferred to avoid self-deadlocks on systems
* with nested onboard hubs.
+ *
+ * If the work is already running wait for it to complete, then
+ * schedule it again to ensure that the USB devices of this onboard
+ * hub instance are bound to the USB driver.
*/
- INIT_WORK(&hub->attach_usb_driver_work, onboard_hub_attach_usb_driver);
- schedule_work(&hub->attach_usb_driver_work);
+ while (work_busy(&attach_usb_driver_work) & WORK_BUSY_RUNNING)
+ msleep(10);
+
+ schedule_work(&attach_usb_driver_work);
return 0;
}
@@ -285,9 +293,6 @@ static int onboard_hub_remove(struct platform_device *pdev)
hub->going_away = true;
- if (&hub->attach_usb_driver_work != current_work())
- cancel_work_sync(&hub->attach_usb_driver_work);
-
mutex_lock(&hub->lock);
/* unbind the USB devices to avoid dangling references to this device */
@@ -449,6 +454,8 @@ static void __exit onboard_hub_exit(void)
{
usb_deregister_device_driver(&onboard_hub_usbdev_driver);
platform_driver_unregister(&onboard_hub_driver);
+
+ cancel_work_sync(&attach_usb_driver_work);
}
module_exit(onboard_hub_exit);
--
2.39.0.314.g84b9a713c41-goog
Powered by blists - more mailing lists