[PATCH net] net: 8139too: cancel the thread work after unregister_netdev()

[PATCH net] net: 8139too: cancel the thread work after unregister_netdev()

[Myeonghun Pak]

rtl8139_remove_one() cancels tp->thread before unregister_netdev().
rtl8139_open() or the TX watchdog can queue it again before the device
is closed, leaving work pending when __rtl8139_cleanup_dev() frees
the netdev and its embedded work.

Move the cancel after unregister_netdev(), which closes the device
and stops the watchdog. The work then sees the device is down and
does not re-arm itself. Synchronous cancellation in rtl8139_close()
could deadlock because it runs under RTNL, which the work also acquires.
Disabling the work before unregister_netdev() would not suffice because
rtl8139_tx_timeout() reinitializes it.

Found by a static analysis tool under development.

Fixes: 83cbb4d25771 ("8139too: RTNL and flush_scheduled_work deadlock")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>

---

 drivers/net/ethernet/realtek/8139too.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/realtek/8139too.c b/drivers/net/ethernet/realtek/8139too.c
index 8241bcf76664..efcf46fd9842 100644
--- a/drivers/net/ethernet/realtek/8139too.c
+++ b/drivers/net/ethernet/realtek/8139too.c
@@ -1103,10 +1103,10 @@ static void rtl8139_remove_one(struct pci_dev *pdev)
 
 	assert (dev != NULL);
 
-	cancel_delayed_work_sync(&tp->thread);
-
 	unregister_netdev (dev);
 
+	cancel_delayed_work_sync(&tp->thread);
+
 	__rtl8139_cleanup_dev (dev);
 	pci_disable_device (pdev);
 }

base-commit: 0edbc945eb9edd0086f25b151a79cfe4adc0dfa8
-- 
2.43.0

Re: [PATCH net] net: 8139too: cancel the thread work after unregister_netdev()

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.