Re: [PATCH net] net: dsa: motorcomm: Do not publish partial MIB sample

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] On weakly ordered 64-bit kernels (arm64, riscv64, ppc64),
  yt921x_dsa_get_stats64() can still combine a new packet count with an…

--

net: dsa: motorcomm: Do not publish partial MIB sample

This patch changes yt921x_mib_read() so that it returns early when a
register read fails. Previously the partially refreshed buffer was copied
into the published u64_stats counters anyway. Now the last complete sample
is kept.

> diff --git a/drivers/net/dsa/motorcomm/mib.c b/drivers/net/dsa/motorcomm/mib.c
> index 6b170fc6e1875..bbcc418fcc871 100644
> --- a/drivers/net/dsa/motorcomm/mib.c
> +++ b/drivers/net/dsa/motorcomm/mib.c
> @@ -127,6 +127,12 @@ static int yt921x_mib_read(struct yt921x_priv *priv, int port)
>  		buf[i] = val;
>  	}
>  
> +	if (res) {
> +		dev_err(dev, "Failed to %s port %d: %i\n", "read stats for",
> +			port, res);
> +		return res;
> +	}
> +
>  	flags = u64_stats_update_begin_irqsave(&pm->syncp);
>  	for (size_t i = 0; i < ARRAY_SIZE(yt921x_mib_descs); i++)
>  		u64_stats_set(&((u64_stats_t *)mib)[i], buf[i]);

[Severity: Medium]
Can yt921x_dsa_get_stats64() still pair a new packet count with an old
byte count on weakly ordered 64-bit machines, even when every register
read succeeds?

On 64-bit kernels, u64_stats_update_begin_irqsave() and
u64_stats_update_end_irqrestore() do no sequencing. u64_stats_set() is a
plain store. This loop stores rx_good_bytes and tx_good_bytes, and then
pm->rx_frames and pm->tx_frames are stored further down with no barrier
between them.

The reader does not take priv->reg_lock. On 64-bit,
u64_stats_fetch_begin() returns 0 and __u64_stats_fetch_retry() always
returns false:

drivers/net/dsa/motorcomm/mib.c:yt921x_dsa_get_stats64() {
    ...
	stats->rx_packets = u64_stats_read(&pm->rx_frames);
	stats->tx_packets = u64_stats_read(&pm->tx_frames);
	stats->rx_bytes = u64_stats_read(&mib->rx_good_bytes) -
			  ETH_FCS_LEN * stats->rx_packets;
    ...
	} while (u64_stats_fetch_retry(&pm->syncp, start));
}

On arm64, riscv64 or ppc64, the stores in yt921x_mib_read() and the loads
in yt921x_dsa_get_stats64() can both be reordered. This applies when the
read comes from yt921x_mib_poll() or from an ethtool-triggered
yt921x_mib_read(). The reader can then see the fresh rx_frames together
with the previous rx_good_bytes.

When ETH_FCS_LEN * new_frames is larger than old_good_bytes, the unsigned
subtraction wraps to about 2^64. Two cases where that holds:

  - the first publication after the per-port stats are allocated, when
    the old byte counters are still zero
  - a burst of traffic on a port that was mostly idle

This is the same symptom the commit message describes:

  "mixing fresh packet counters with stale byte counters; get_stats64 then
  subtracts ETH_FCS_LEN per packet from the stale byte counter and
  underflows on unsigned arithmetic."

The patch removes the read-failure trigger. A complete published sample
still doesn't give the reader a consistent view of several fields on
64-bit, though.

Would it make sense to clamp the subtraction in yt921x_dsa_get_stats64()?
Another option is to compute the FCS-adjusted byte counts in
yt921x_mib_read() and publish those instead.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261102101334.3525485-1-mmyangfl%40gmail.com