Re: [PATCH net] octeontx2-pf: fix XDP frames freed as skbs on interface down

[Nicolai Buchwitz <nb@tipi-net.de>]

On 2.11.2026 21:12, netdev-bot+sashiko@kernel.org wrote:

> [...]

> [Severity: Medium]
> The new CQ_XDP branch fills in xsk_frames, but is it ever used after
> the loop?

Daniel already pointed this out. Will fix this in v2.

> [...]

> [Severity: Medium]
> Should xsk_frames be reported back to the XSK pool after this loop?

Same. Will fix this in v2.

> [...]

> [Severity: Medium]
> This is a pre-existing issue, but it is on the same XDP teardown path.
> otx2_free_pending_sqe() only walks the regular TX SQs:
> [...]
> [Severity: High]
> This isn't a bug introduced by this patch. The commit message mentions
> "when the XDP program is replaced". On that path, is ndo_xdp_xmit kept
> away from the XDP SQ teardown?
> [...]
> [Severity: High]
> This is a pre-existing issue, but can NAPI run at the same time as this
> cleanup loop? otx2_stop() does:

All three pre-existing issues will probably need to change the teardown 
ordering.
As I don't have any hardware to test, this is probably better done by 
the maintainers.

> [...]

> [Severity: High]
> This isn't a bug introduced by this patch. However, the new branch adds
> another consumer of sg->skb values that may be bogus in AF_XDP 
> zero-copy
> mode.

Also pre-existing and this seems worth fixing in another patch. AFAIU 
the zero
copy branch can jump past the buffer init, so XDP_TX and _PASS would 
work with
an uninitialized xdp_buff. The fix is probably to switch to
xdp_convert_buff_to_frame(xsk_buff) for TX and xdp_build_skb_from_zc for 
PASS.

Ideally someone with hardware would fix this ... Marvell?

> [...]

--
pw-bot: cr