Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Deadlock on 32-bit systems due to u64_stats_update_begin with preemption enabled --
commit 9fbccd82cfbdb308859b32b732f45f8415ee4bd0 Author: Long Li <[email protected]> net: mana: swap queue sets in mana_change_mtu This commit carries the MTU in the queue set and replaces the RX buffers from it. It swaps queue sets in mana_change_mtu by allocating a new scratch context, publishing the new queue set, and cleaning up the old one upon success or failure. > diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c > b/drivers/net/ethernet/microsoft/mana/mana_en.c > --- a/drivers/net/ethernet/microsoft/mana/mana_en.c > +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c [ ... ] > @@ -4392,6 +4419,8 @@ int mana_publish_qset(struct mana_port_context *apc, > struct mana_qset *newq, > synchronize_net(); > mana_fold_qset_rx_stats(apc, out_old); > > + WRITE_ONCE(ndev->mtu, apc->configured_mtu); > + > /* Publish restored fields before reopening the gate, as on success. */ > smp_wmb(); [Severity: High] Can this lead to a deadlock on 32-bit systems? The mana_publish_qset function executes under the rtnl lock with preemption enabled, which leads to this call chain: mana_publish_qset() mana_fold_qset_rx_stats() mana_fold_rxq_stats() { u64_stats_update_begin(&dst->syncp); dst->packets += src->packets; dst->bytes += src->bytes; ... u64_stats_update_end(&dst->syncp); } Because preemption is enabled, on 32-bit architectures, a reader such as ndo_get_stats64() could preempt the writer while the sequence count is odd. The reader would then spin forever in u64_stats_fetch_retry() waiting for an even sequence count, starving the preempted writer and resulting in a deadlock. Should preemption or interrupts be disabled around this stats update to ensure readers cannot preempt the writer? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=7
