[randomizedcoder]

homa_qdisc_deferred_offset() reads a deferred RPC's packet queue length and qrpc.tx_left without qdev->defer_lock, while the pacer changes both under that lock. The comment says the race is intended (a slightly stale result is fine), but the reads are plain loads, so KCSAN reports it:

BUG: KCSAN: data-race in homa_qdisc_get_deferred_homa [homa] / homa_rpc_tx_end [homa]
write (marked) ... homa_qdisc_get_deferred_homa <- homa_qdisc_xmit_deferred_homa <- homa_qdisc_pacer
read ... homa_rpc_tx_end <- homa_timer_check_rpc <- homa_timer
value changed: 0x00000086 -> 0x00000084

Fix: annotate the intended race.

• skb_queue_len_lockless() for the length (__skb_unlink already writes qlen with WRITE_ONCE).
• READ_ONCE(rpc->qrpc.tx_left) there, and WRITE_ONCE at the two stores in homa_qdisc.c.
• The readers that hold defer_lock stay plain.

No behaviour change.

Checked:

• 884/884 unit tests pass; the 7.3 module builds normally and with __STRIP__=1.
• On a KCSAN guest kernel, a two-VM run with Homa's qdisc and pacer on. The race is timing-dependent: without the fix it showed in 1 of 2 runs. With the fix, 3 runs in a row were clean. That's good evidence but not proof.

No test, since it's an annotation only.

🤖 Generated with Claude Code