[PATCH net v2] net: fix spurious TX timeout after dev_activate()

While debugging another issue today, I found out that my TX queue is
reported as stopped for 4294907392 ms (49.7 days), on a machine that
had been up for four minutes.

    bnxt_en 0002:01:00.0 eth0: NETDEV WATCHDOG: CPU: 28: transmit queue 23 timed out 4294907392 ms

4294907392 is not an elapsed time. It is the value of jiffies at that
moment: INITIAL_JIFFIES is 4294667296, which leaves jiffies 59 seconds
short of wrapping.

dev_activate() runs transition_one_qdisc() over every TX queue, which
resets trans_start to 0, and then stamps only queue 0 through
netif_trans_update().

Stamp jiffies instead. A queue stopped across dev_activate() now gets a
full watchdog_timeo of grace, and is still reported if it is stopped
that long.

Fixes: 9b36627acecd ("net: remove dev->trans_start")
Cc: [email protected]
Signed-off-by: Breno Leitao <[email protected]>
Reviewed-by: Nicolai Buchwitz <[email protected]>
---
The redundant netif_trans_update() in dev_activate() that Nicolai
spotted is a separate cleanup, and will be sent against net-next.

Changes in v2:
- Fix the unit error in the changelog: 4294907392 ms is 49.7 days, not
  136 years. Also note the machine had only been up four minutes, which
  makes the bogus delta obvious (Nicolai Buchwitz).
- Collect Reviewed-by from Nicolai Buchwitz.
- Link to v1: https://patch.msgid.link/[email protected]
---
 net/sched/sch_generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index ef2b4bf515641..4539dc2c6d380 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -1278,7 +1278,7 @@ static void transition_one_qdisc(struct net_device *dev,
 
 	rcu_assign_pointer(dev_queue->qdisc, new_qdisc);
 	if (need_watchdog_p) {
-		WRITE_ONCE(dev_queue->trans_start, 0);
+		WRITE_ONCE(dev_queue->trans_start, jiffies);
 		*need_watchdog_p = 1;
 	}
 }

---
base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
change-id: 20260824-trans_start-557ecd4c8866

Best regards,
--  
Breno Leitao <[email protected]>