rtl8152_system_resume() issues a synchronous usb reset if the device is
inaccessible. __rtl8152_set_mac_address() is called via
rtl8152_post_reset() and it tries to take the same mutex that was already
taken in rtl8152_resume(). Move the call to reset usb in rtl8152_resume()
outside mutex protection.

Signed-off-by: George-Daniel Matei <danielgeorgem@chromium.org>
---
 drivers/net/usb/r8152.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a5612c799f5e..69d66ce7a5c5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -8564,19 +8564,6 @@ static int rtl8152_system_resume(struct r8152 *tp)
 		usb_submit_urb(tp->intr_urb, GFP_NOIO);
 	}
 
-	/* If the device is RTL8152_INACCESSIBLE here then we should do a
-	 * reset. This is important because the usb_lock_device_for_reset()
-	 * that happens as a result of usb_queue_reset_device() will silently
-	 * fail if the device was suspended or if too much time passed.
-	 *
-	 * NOTE: The device is locked here so we can directly do the reset.
-	 * We don't need usb_lock_device_for_reset() because that's just a
-	 * wrapper over device_lock() and device_resume() (which calls us)
-	 * does that for us.
-	 */
-	if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
-		usb_reset_device(tp->udev);
-
 	return 0;
 }
 
@@ -8681,6 +8668,19 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
 
 	mutex_unlock(&tp->control);
 
+	/* If the device is RTL8152_INACCESSIBLE here then we should do a
+	 * reset. This is important because the usb_lock_device_for_reset()
+	 * that happens as a result of usb_queue_reset_device() will silently
+	 * fail if the device was suspended or if too much time passed.
+	 *
+	 * NOTE: The device is locked here so we can directly do the reset.
+	 * We don't need usb_lock_device_for_reset() because that's just a
+	 * wrapper over device_lock() and device_resume() (which calls us)
+	 * does that for us.
+	 */
+	if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
+		usb_reset_device(tp->udev);
+
 	return ret;
 }
 
-- 
2.47.0.rc1.288.g06298d1525-goog

Hi,

On Fri, Oct 18, 2024 at 7:13 AM George-Daniel Matei
<danielgeorgem@chromium.org> wrote:
>
> rtl8152_system_resume() issues a synchronous usb reset if the device is
> inaccessible. __rtl8152_set_mac_address() is called via
> rtl8152_post_reset() and it tries to take the same mutex that was already
> taken in rtl8152_resume().

Thanks for the fix! I'm 99% certain I tested the original code, but I
guess somehow I ran a different code path. I just put my old hacky
test patch [1] back on and re-tested this to see what happened. OK, I
see. In my case dev_set_mac_address() gets called at resume time but
then the address hasn't changed so "ops->ndo_set_mac_address()" (which
points to rtl8152_set_mac_address()) never gets called and I don't end
up in the deadlock. I wonder why the MAC address changed for you. In
any case, the deadlock is real and I agree that this should be fixed.

BTW: it would be handy to include the call stack of the deadlock in
your commit message.

[1] https://crrev.com/c/5543125

> Move the call to reset usb in rtl8152_resume()
> outside mutex protection.
>
> Signed-off-by: George-Daniel Matei <danielgeorgem@chromium.org>

Before your Signed-off-by you should have:

Fixes: 4933b066fefb ("r8152: If inaccessible at resume time, issue a reset")


> ---
>  drivers/net/usb/r8152.c | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index a5612c799f5e..69d66ce7a5c5 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -8564,19 +8564,6 @@ static int rtl8152_system_resume(struct r8152 *tp)
>                 usb_submit_urb(tp->intr_urb, GFP_NOIO);
>         }
>
> -       /* If the device is RTL8152_INACCESSIBLE here then we should do a
> -        * reset. This is important because the usb_lock_device_for_reset()
> -        * that happens as a result of usb_queue_reset_device() will silently
> -        * fail if the device was suspended or if too much time passed.
> -        *
> -        * NOTE: The device is locked here so we can directly do the reset.
> -        * We don't need usb_lock_device_for_reset() because that's just a
> -        * wrapper over device_lock() and device_resume() (which calls us)
> -        * does that for us.
> -        */
> -       if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
> -               usb_reset_device(tp->udev);
> -
>         return 0;
>  }
>
> @@ -8681,6 +8668,19 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
>
>         mutex_unlock(&tp->control);
>
> +       /* If the device is RTL8152_INACCESSIBLE here then we should do a
> +        * reset. This is important because the usb_lock_device_for_reset()
> +        * that happens as a result of usb_queue_reset_device() will silently
> +        * fail if the device was suspended or if too much time passed.
> +        *
> +        * NOTE: The device is locked here so we can directly do the reset.
> +        * We don't need usb_lock_device_for_reset() because that's just a
> +        * wrapper over device_lock() and device_resume() (which calls us)
> +        * does that for us.
> +        */
> +       if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
> +               usb_reset_device(tp->udev);

You seem to have moved this to the wrong function. It should be in
rtl8152_resume() but you've moved it to rtl8152_suspend(). As you have
it here you'll avoid the deadlock but I fear you may end up missing a
reset. Maybe you didn't notice this because commit 8c1d92a740c0
("r8152: Wake up the system if the we need a reset") woke us up
quickly enough and the previous reset hadn't expired yet?

In any case, please move it to the rtl8152_resume() function, re-test,
and post a new version.

-Doug