[PATCH net-next v1 1/1] net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

[PATCH net-next v1 1/1] net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

[Oleksij Rempel]

A WARN may be triggered in __netif_napi_del_locked() during USB device
disconnect:

  WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350

This occurs because NAPI remains enabled when the device is unplugged and
teardown begins. While `napi_disable()` was previously called in the
`lan78xx_stop()` path, that function is not invoked on disconnect. Instead,
when using PHYLINK, the `mac_link_down()` callback is guaranteed to run
during disconnect, making it the correct place to disable NAPI.

Similarly, move `napi_enable()` to `mac_link_up()` to pair the lifecycle
with actual MAC state.

Full trace:
 lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV
 lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV
 lan78xx 1-1:1.0 enu1: Link is Down
 lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
 Modules linked in: flexcan can_dev fuse
 CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT
 Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)
 Workqueue: usb_hub_wq hub_event
 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __netif_napi_del_locked+0x2b4/0x350
 lr : __netif_napi_del_locked+0x7c/0x350
 sp : ffffffc085b673c0
 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8
 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb
 x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000
 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000
 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028
 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8
 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000
 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001
 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000
 Call trace:
  __netif_napi_del_locked+0x2b4/0x350 (P)
  lan78xx_disconnect+0xf4/0x360
  usb_unbind_interface+0x158/0x718
  device_remove+0x100/0x150
  device_release_driver_internal+0x308/0x478
  device_release_driver+0x1c/0x30
  bus_remove_device+0x1a8/0x368
  device_del+0x2e0/0x7b0
  usb_disable_device+0x244/0x540
  usb_disconnect+0x220/0x758
  hub_event+0x105c/0x35e0
  process_one_work+0x760/0x17b0
  worker_thread+0x768/0xce8
  kthread+0x3bc/0x690
  ret_from_fork+0x10/0x20
 irq event stamp: 211604
 hardirqs last  enabled at (211603): [<ffffffc0828cc9ec>] _raw_spin_unlock_irqrestore+0x84/0x98
 hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1_dbg+0x24/0x80
 softirqs last  enabled at (211296): [<ffffffc080095f10>] handle_softirqs+0x820/0xbc8
 softirqs last disabled at (210993): [<ffffffc080010288>] __do_softirq+0x18/0x20
 ---[ end trace 0000000000000000 ]---
 lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
This patch is intended for `net-next` since the issue existed before the
PHYLINK migration, but is more naturally and cleanly addressed now that
PHYLINK manages link state transitions.
---
 drivers/net/usb/lan78xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 565b9847e2ab..598fe0390112 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2281,6 +2281,7 @@ static void lan78xx_mac_link_down(struct phylink_config *config,
 	int ret;

 	netif_stop_queue(net);
+	napi_disable(&dev->napi);

 	/* MAC reset will not de-assert TXEN/RXEN, we need to stop them
 	 * manually before reset. TX and RX should be disabled before running
@@ -2505,6 +2506,7 @@ static void lan78xx_mac_link_up(struct phylink_config *config,
 	if (ret < 0)
 		goto link_up_fail;

+	napi_enable(&dev->napi);
 	netif_start_queue(net);

 	return;
@@ -3421,7 +3423,6 @@ static int lan78xx_open(struct net_device *net)

 	lan78xx_init_stats(dev);

-	napi_enable(&dev->napi);

 	set_bit(EVENT_DEV_OPEN, &dev->flags);

@@ -3494,7 +3495,6 @@ static int lan78xx_stop(struct net_device *net)
 		timer_delete_sync(&dev->stat_monitor);

 	clear_bit(EVENT_DEV_OPEN, &dev->flags);
-	napi_disable(&dev->napi);

 	lan78xx_terminate_urbs(dev);

--
2.39.5

Re: [PATCH net-next v1 1/1] net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

[Jakub Kicinski]

On Fri, 20 Jun 2025 10:51:44 +0200 Oleksij Rempel wrote:
> A WARN may be triggered in __netif_napi_del_locked() during USB device
> disconnect:
> 
>   WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
> 
> This occurs because NAPI remains enabled when the device is unplugged and
> teardown begins. While `napi_disable()` was previously called in the
> `lan78xx_stop()` path, that function is not invoked on disconnect. Instead,
> when using PHYLINK, the `mac_link_down()` callback is guaranteed to run
> during disconnect, making it the correct place to disable NAPI.
> 
> Similarly, move `napi_enable()` to `mac_link_up()` to pair the lifecycle
> with actual MAC state.

Stopping and starting NAPI on link events is pretty unusual.
The problem is the disconnect handling, unregistering netdev
removes the NAPIs automatically, I think all you need is to
remove the explicit netif_napi_del() in lan78xx_disconnect().
Core will call _stop (which disables the NAPI), and then
it will del the NAPI.

> This patch is intended for `net-next` since the issue existed before the
> PHYLINK migration, but is more naturally and cleanly addressed now that
> PHYLINK manages link state transitions.

And repost that for net, please.. :)
-- 
pw-bot: cr

Re: [PATCH net-next v1 1/1] net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

[Oleksij Rempel]

On Mon, Jun 23, 2025 at 04:55:37PM -0700, Jakub Kicinski wrote:
> On Fri, 20 Jun 2025 10:51:44 +0200 Oleksij Rempel wrote:
> > A WARN may be triggered in __netif_napi_del_locked() during USB device
> > disconnect:
> > 
> >   WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
> > 
> > This occurs because NAPI remains enabled when the device is unplugged and
> > teardown begins. While `napi_disable()` was previously called in the
> > `lan78xx_stop()` path, that function is not invoked on disconnect. Instead,
> > when using PHYLINK, the `mac_link_down()` callback is guaranteed to run
> > during disconnect, making it the correct place to disable NAPI.
> > 
> > Similarly, move `napi_enable()` to `mac_link_up()` to pair the lifecycle
> > with actual MAC state.
> 
> Stopping and starting NAPI on link events is pretty unusual.
> The problem is the disconnect handling, unregistering netdev
> removes the NAPIs automatically, I think all you need is to
> remove the explicit netif_napi_del() in lan78xx_disconnect().
> Core will call _stop (which disables the NAPI), and then
> it will del the NAPI.

ack.

> > This patch is intended for `net-next` since the issue existed before the
> > PHYLINK migration, but is more naturally and cleanly addressed now that
> > PHYLINK manages link state transitions.
> 
> And repost that for net, please.. :)

It will be not compatible with the PHYlink migration patch in the
net-next. Should i wait until PHYlink patch goes to the net and then
send different patch variants for stable before PHYlink migration and
after?

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH net-next v1 1/1] net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect

[Jakub Kicinski]

On Thu, 26 Jun 2025 12:18:29 +0200 Oleksij Rempel wrote:
> > > This patch is intended for `net-next` since the issue existed before the
> > > PHYLINK migration, but is more naturally and cleanly addressed now that
> > > PHYLINK manages link state transitions.  
> > 
> > And repost that for net, please.. :)  
> 
> It will be not compatible with the PHYlink migration patch in the
> net-next. Should i wait until PHYlink patch goes to the net and then
> send different patch variants for stable before PHYlink migration and
> after?

The conflict will be relatively easy, we will have to cope.
But you really, really should hold off net-next patches until 
you fix all the pre-existing bugs :|