Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] False-positive ASSERT_RTNL() warning during probe failure. --
commit b6c8581e036e2f21afeed4eb0d2e9961d1a0d2f5 Author: Long Li <[email protected]> Subject: net: mana: keep per-queue statistics in the port context This patch moves rx and tx statistics from the individual queue structures into port-context arrays. This ensures that the interface counters are not lost across reconfigurations such as ethtool channel count or MTU changes. > 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 [ ... ] > +static void mana_fold_rxq_stats(struct mana_port_context *apc, > + struct mana_rxq *rxq) > +{ > + struct mana_stats_rx *src = &rxq->drain_stats; > + struct mana_stats_rx *dst; > + unsigned int i; > + > + ASSERT_RTNL(); [ ... ] > @@ -3017,6 +3163,11 @@ static void mana_destroy_rxq(struct mana_port_context > *apc, > netif_napi_del_locked(napi); > } > > + /* No poller left, so this is the last chance to keep what the queue > + * counted after it stopped being the live one. > + */ > + mana_fold_rxq_stats(apc, rxq); > + [Severity: Medium] Will this trigger a false-positive ASSERT_RTNL() warning if the driver fails to probe? If mana_init_port() fails during device probe (e.g., due to a memory allocation failure or hardware timeout), the error recovery path calls mana_destroy_rxqs() and then mana_destroy_rxq(), which now unconditionally calls mana_fold_rxq_stats(). Since the probe path in mana_probe_port() invokes mana_init_port() before calling register_netdev(), the RTNL lock is not held yet. This seems like it would trigger the new ASSERT_RTNL() inside mana_fold_rxq_stats() during a valid error recovery path. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=9
