Re: [PATCH net-next 06/10] net/mlx5e: Add data direct TX infrastructure

From: netdev-bot+sashiko

Date: Mon Oct 12 2026 - 11:43:34 EST


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

Critical: 0 · High: 1 · Medium: 0 · 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).

- [High] net/mlx5e: GPU unbind causes DMA corruption for active devmem TX

--

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
> @@ -211,7 +212,8 @@ mlx5e_txwqe_build_dsegs(struct mlx5e_txqsq *sq, struct sk_buff *skb,
> goto dma_unmap_wqe_err;
>
> dseg->addr = cpu_to_be64(dma_addr);
> - dseg->lkey = sq->mkey_be;
> + dseg->lkey = dd && skb_frag_is_net_iov(frag) ?
> + sq->crossing_mkey_be : sq->mkey_be;
> dseg->byte_count = cpu_to_be32(fsz);
>
> mlx5e_dma_push_netmem(sq, skb_frag_netmem(frag), dma_addr, fsz);

[Severity: High]
When MLX5E_SQ_STATE_DATA_DIRECT is clear, this silently falls back to
sq->mkey_be for net_iov frags too. That only works if a net_iov can
never reach an SQ whose data direct state differs from the device the
net_iov was DMA mapped against. Nothing on the TX side enforces that.

The follow-up "net/mlx5e: Recreate netdev channels on data direct
device unbind" makes this reachable. On unbind,
mlx5e_data_direct_event() clears MLX5E_PFLAG_DATA_DIRECT and recreates
the channels. It does not do the netdev_has_dmabuf_binding() check
that the ethtool path does, so a devmem TX binding made while data
direct was on stays alive.

That binding was mapped against the device returned by
netdev_queue_get_dma_dev(), so its net_iov DMA addresses are IOVAs in
that device's domain. After the channels are recreated, dd is false in
mlx5e_txwqe_build_dsegs(). The same IOVAs then get posted with the
local mkey, and the NIC reads whatever they happen to resolve to in
its own domain. The result is silent corruption of transmitted data or
IOMMU faults, rather than a clean error to the sender.

How is a still-bound TX dmabuf supposed to survive the unbind? Should
the binding be invalidated before the queues are restarted? Or should
net_iov frags be dropped here when dd is false, instead of being sent
with sq->mkey_be?

--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261008132815.654147-1-tariqt%40nvidia.com