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

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

[David Yang]

When a register read failed midway, the buffer was published anyway,
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.

Keep the last complete sample instead.

Fixes: 186623f4aa72 ("net: dsa: yt921x: Add support for Motorcomm YT921x")
Signed-off-by: David Yang <mmyangfl@gmail.com>
---
 drivers/net/dsa/motorcomm/mib.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/motorcomm/mib.c b/drivers/net/dsa/motorcomm/mib.c
index 6b170fc6e187..bbcc418fcc87 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]);
@@ -148,10 +154,7 @@ static int yt921x_mib_read(struct yt921x_priv *priv, int port)
 	u64_stats_set(&pm->tx_frames, tx_frames);
 	u64_stats_update_end_irqrestore(&pm->syncp, flags);
 
-	if (res)
-		dev_err(dev, "Failed to %s port %d: %i\n", "read stats for",
-			port, res);
-	return res;
+	return 0;
 }
 
 void yt921x_mib_poll(struct work_struct *work)
-- 
2.53.0

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

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

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

[David Yang]

On Mon, Nov 2, 2026 at 6:19 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Reported by sashiko

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