On Tue, 8 Apr 2025 11:28:54 +0200 Paolo Abeni wrote: > >> When napi_disable is called on an already disabled napi, it will sleep > >> in napi_disable_locked while still holding the netdev_lock. As a result, > >> later napi_enable gets stuck too as it cannot acquire the netdev_lock. > >> This leads to refill_work and the pause-then-resume tx are stuck altogether. > > > > This needs to be added to the chagelog. And it looks like this is a fix for > > > > commit 413f0271f3966e0c73d4937963f19335af19e628 > > Author: Jakub Kicinski <kuba@xxxxxxxxxx> > > Date: Tue Jan 14 19:53:14 2025 -0800 > > > > net: protect NAPI enablement with netdev_lock() > > > > ? > > > > I wonder if it's simpler to just hold the netdev lock in resize or xsk > > binding instead of this. > > Setting: > > dev->request_ops_lock = true; > > in virtnet_probe() before calling register_netdevice() should achieve > the above. Could you please have a try? Can we do that or do we need a more tailored fix? request_ops_lock only appeared in 6.15 and the bug AFAIU dates back to 6.14. We don't normally worry about given the stream of fixes - request_ops_lock is a bit risky. Jason's suggestion AFAIU is just to wrap the disable/enable pairs in the lock. We can try request_ops_lock in -next ? Bui Quang Minh, could you add a selftest for this problem? See tools/testing/selftests/drivers/net/virtio_net/ You can re-use / extend the XSK helper from tools/testing/selftests/drivers/net/xdp_helper.c ? (move it to tools/testing/selftests/net/lib for easier access)
