[PATCH net] net: stmmac: avoid duplicate XSK TX completions
James Hilliard
james.hilliard1 at gmail.com
Tue Oct 13 13:52:22 PDT 2026
On Tue, Oct 13, 2026 at 2:40 PM <netdev-bot+sinfo at 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.
This was flagged during Sashiko review of the larger stmmac recovery
series, then confirmed by inspecting the existing TX completion and
teardown paths. The bug exists independently of that series.
> - 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.
The duplicate accounting was reproduced in a local KUnit test under
QEMU using the actual driver cleanup functions and AF_XDP completion
queue code. With three completed XSK descriptors, teardown published
another three completions on the unpatched code. With the fix, the
total remained three.
The practical trigger is bringing the interface down after AF_XDP
zero-copy transmission while leaving the socket bound. No allocation
failure or hardware fault is required.
> - What hardware the change was tested on. For driver fixes please
> mention the device (and if relevant firmware version) used for
> testing, or say that the change was not tested on real hardware.
This change has not been tested on physical stmmac hardware. Validation
used the software regression tests above and ARM64/i386 compile checks.
> 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.
More information about the linux-arm-kernel
mailing list