When the dim worker is scheduled, if it fails to acquire the lock,
dim may not be able to return to the working state later.
For example, the following single queue scenario:
1. The dim worker of rxq0 is scheduled, and the dim status is
changed to DIM_APPLY_NEW_PROFILE;
2. The ethtool command is holding rtnl lock;
3. Since the rtnl lock is already held, virtnet_rx_dim_work fails
to acquire the lock and exits;
Then, even if net_dim is invoked again, it cannot work because the
state is not restored to DIM_START_MEASURE.
Fixes: 6208799553a8 ("virtio-net: support rx netdim")
Signed-off-by: Heng Qi <hengqi@xxxxxxxxxxxxxxxxx>
---
drivers/net/virtio_net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index c22d111..0ebe322 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -3563,8 +3563,10 @@ static void virtnet_rx_dim_work(struct work_struct *work)
struct dim_cq_moder update_moder;
int i, qnum, err;
- if (!rtnl_trylock())
+ if (!rtnl_trylock()) {
+ schedule_work(&dim->work);
return;
+ }
/* Each rxq's work is queued by "net_dim()->schedule_work()"
* in response to NAPI traffic changes. Note that dim->profile_ix
--
1.8.3.1
