Thread (12 messages) 12 messages, 5 authors, 2021-12-22

Re: [PATCH net] igb: fix deadlock caused by taking RTNL in RPM resume path

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-11-30 17:12:14
Also in: intel-wired-lan

On Tue, 30 Nov 2021 07:46:22 +0100 Heiner Kallweit wrote:
On 30.11.2021 02:17, Jakub Kicinski wrote:
quoted
On Mon, 29 Nov 2021 22:14:06 +0100 Heiner Kallweit wrote:  
quoted
-	rtnl_lock();
+	if (!rpm)
+		rtnl_lock();  
Is there an ASSERT_RTNL() hidden in any of the below? Can we add one?
Unless we're 100% confident nobody will RPM resume without rtnl held..
  
Not sure whether igb uses RPM the same way as r8169. There the device
is runtime-suspended (D3hot) w/o link. Once cable is plugged in the PHY
triggers a PME, and PCI core runtime-resumes the device (MAC).
In this case RTNL isn't held by the caller. Therefore I don't think
it's safe to assume that all callers hold RTNL.
No, no - I meant to leave the locking in but add ASSERT_RTNL() to catch
if rpm == true && rtnl_held() == false.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help