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
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.