On Thu, 22 Oct 2026 16:03:36 +0000 netdev-bot+sinfo@kernel.org wrote:
- How the issue was discovered, e.g. hit in production, hit during
development, syzbot report, manual code inspection, LLM or static
analysis tool scan.
The original problem was found during development, not in production.
While preparing the net-next RFC v2 [1], which extended the CPU MAC
pause in qca8k_port_change_mtu() to internal CPU ports, I asked an LLM
agent for an adversarial review of that change. The review found that
the existing sequence re-enables the port 0 and 6 MACs after phylink
has taken the link down, and that phylink callbacks can run during the
update.
The problems fixed in v6 and v7 were reported by Sashiko on v5 and v6.
I reproduced them, and the original problem with the unpatched code,
in a userspace harness that compiles the driver and DSA MTU functions
with mocked register access. None of them has been reproduced on
hardware, and v7 has not been tested on hardware.
Sashiko's review of v7 is a separate question and is still open.
[1] https://lore.kernel.org/netdev/20260922202653.1153-1-yongzhao.derek@gmail.com/ (local)
Thanks,
Yongzhao Chen