[PATCH 0/2] r8152: Fix a couple of PM problems

STALE1867d

5 messages, 3 authors, 2021-07-15 · open the first message on its own page

[PATCH 0/2] r8152: Fix a couple of PM problems

From: Takashi Iwai <hidden>
Date: 2021-07-14 17:00:31

Hi,

it seems that r8152 driver suffers from the deadlock at both runtime
and system PM.  Formerly, it was seen more often at hibernation
resume, but now it's triggered more frequently, as reported in SUSE
Bugzilla:
  https://bugzilla.suse.com/show_bug.cgi?id=1186194

While debugging the problem, I stumbled on a few obvious bugs and here
is the results with two patches for addressing the resume problem.

***

However, the story doesn't end here, unfortunately, and those patches
don't seem sufficing.  The rest major problem is that the driver calls
napi_disable() and napi_enable() in the PM suspend callbacks.  This
makes the system stalling at (runtime-)suspend.  If we drop
napi_disable() and napi_enable() calls in the PM suspend callbacks, it
starts working (that was the result in Bugzilla comment 13):
  https://bugzilla.suse.com/show_bug.cgi?id=1186194#c13

So, my patches aren't enough and we still need to investigate
further.  It'd be appreciated if anyone can give a fix or a hint for
more debugging.  The usage of napi_disable() at PM callbacks is unique
in this driver and looks rather suspicious to me; but I'm no expert in
this area so I might be wrong...


Thanks!

Takashi

===

Takashi Iwai (2):
  r8152: Fix potential PM refcount imbalance
  r8152: Fix a deadlock by doubly PM resume

 drivers/net/usb/r8152.c | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

-- 
2.26.2

[PATCH 1/2] r8152: Fix potential PM refcount imbalance

From: Takashi Iwai <hidden>
Date: 2021-07-14 17:00:30

rtl8152_close() takes the refcount via usb_autopm_get_interface() but
it doesn't release when RTL8152_UNPLUG test hits.  This may lead to
the imbalance of PM refcount.  This patch addresses it.

Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194
Signed-off-by: Takashi Iwai <redacted>
---
 drivers/net/usb/r8152.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1692d3b1b6e1..4096e20e9725 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -6763,9 +6763,10 @@ static int rtl8152_close(struct net_device *netdev)
 		tp->rtl_ops.down(tp);
 
 		mutex_unlock(&tp->control);
+	}
 
+	if (!res)
 		usb_autopm_put_interface(tp->intf);
-	}
 
 	free_all_mem(tp);
 
-- 
2.26.2

[PATCH 2/2] r8152: Fix a deadlock by doubly PM resume

From: Takashi Iwai <hidden>
Date: 2021-07-14 17:00:32

r8152 driver sets up the MAC address at reset-resume, while
rtl8152_set_mac_address() has the temporary autopm get/put.  This may
lead to a deadlock as the PM lock has been already taken for the
execution of the runtime PM callback.

This patch adds the workaround to avoid the superfluous autpm when
called from rtl8152_reset_resume().

Link: https://bugzilla.suse.com/show_bug.cgi?id=1186194
Signed-off-by: Takashi Iwai <redacted>
---
 drivers/net/usb/r8152.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4096e20e9725..e09b107b5c99 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1552,7 +1552,8 @@ static int
 rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
 		  u32 advertising);
 
-static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
+static int __rtl8152_set_mac_address(struct net_device *netdev, void *p,
+				     bool in_resume)
 {
 	struct r8152 *tp = netdev_priv(netdev);
 	struct sockaddr *addr = p;
@@ -1561,9 +1562,11 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
 	if (!is_valid_ether_addr(addr->sa_data))
 		goto out1;
 
-	ret = usb_autopm_get_interface(tp->intf);
-	if (ret < 0)
-		goto out1;
+	if (!in_resume) {
+		ret = usb_autopm_get_interface(tp->intf);
+		if (ret < 0)
+			goto out1;
+	}
 
 	mutex_lock(&tp->control);
 
@@ -1575,11 +1578,17 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
 
 	mutex_unlock(&tp->control);
 
-	usb_autopm_put_interface(tp->intf);
+	if (!in_resume)
+		usb_autopm_put_interface(tp->intf);
 out1:
 	return ret;
 }
 
+static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
+{
+	return __rtl8152_set_mac_address(netdev, p, false);
+}
+
 /* Devices containing proper chips can support a persistent
  * host system provided MAC address.
  * Examples of this are Dell TB15 and Dell WD15 docks
@@ -1698,7 +1707,7 @@ static int determine_ethernet_addr(struct r8152 *tp, struct sockaddr *sa)
 	return ret;
 }
 
-static int set_ethernet_addr(struct r8152 *tp)
+static int set_ethernet_addr(struct r8152 *tp, bool in_resume)
 {
 	struct net_device *dev = tp->netdev;
 	struct sockaddr sa;
@@ -1711,7 +1720,7 @@ static int set_ethernet_addr(struct r8152 *tp)
 	if (tp->version == RTL_VER_01)
 		ether_addr_copy(dev->dev_addr, sa.sa_data);
 	else
-		ret = rtl8152_set_mac_address(dev, &sa);
+		ret = __rtl8152_set_mac_address(dev, &sa, in_resume);
 
 	return ret;
 }
@@ -8444,7 +8453,7 @@ static int rtl8152_reset_resume(struct usb_interface *intf)
 	clear_bit(SELECTIVE_SUSPEND, &tp->flags);
 	tp->rtl_ops.init(tp);
 	queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0);
-	set_ethernet_addr(tp);
+	set_ethernet_addr(tp, true);
 	return rtl8152_resume(intf);
 }
 
@@ -9645,7 +9654,7 @@ static int rtl8152_probe(struct usb_interface *intf,
 	tp->rtl_fw.retry = true;
 #endif
 	queue_delayed_work(system_long_wq, &tp->hw_phy_work, 0);
-	set_ethernet_addr(tp);
+	set_ethernet_addr(tp, false);
 
 	usb_set_intfdata(intf, tp);
 
-- 
2.26.2

Re: [PATCH 0/2] r8152: Fix a couple of PM problems

From: patchwork-bot+netdevbpf@kernel.org
Date: 2021-07-14 22:00:07

Hello:

This series was applied to netdev/net.git (refs/heads/master):

On Wed, 14 Jul 2021 19:00:20 +0200 you wrote:
Hi,

it seems that r8152 driver suffers from the deadlock at both runtime
and system PM.  Formerly, it was seen more often at hibernation
resume, but now it's triggered more frequently, as reported in SUSE
Bugzilla:
  https://bugzilla.suse.com/show_bug.cgi?id=1186194

[...]
Here is the summary with links:
  - [1/2] r8152: Fix potential PM refcount imbalance
    https://git.kernel.org/netdev/net/c/9c23aa51477a
  - [2/2] r8152: Fix a deadlock by doubly PM resume
    https://git.kernel.org/netdev/net/c/776ac63a986d

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

RE: [PATCH 0/2] r8152: Fix a couple of PM problems

From: Hayes Wang <hidden>
Date: 2021-07-15 04:37:07

Subject: Re: [PATCH 0/2] r8152: Fix a couple of PM problems
[...]
Here is the summary with links:
  - [1/2] r8152: Fix potential PM refcount imbalance
    https://git.kernel.org/netdev/net/c/9c23aa51477a
  - [2/2] r8152: Fix a deadlock by doubly PM resume
    https://git.kernel.org/netdev/net/c/776ac63a986d
I think set_ethernet_addr() shouldn't be called at reset-resume.
The MAC address should be restored to the current one, not the
default value. Someone may change the MAC address before suspending.
And the MAC address would become the default value after reset-resume,
if set_ethernet_addr() is called.

Best Regards,
Hayes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help