mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: tariqt@nvidia.com
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
	kuba@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com,
	bobbyeshleman@meta.com, byungchul@sk.com, cjubran@nvidia.com,
	cratiu@nvidia.com, dtatulea@nvidia.com, gal@nvidia.com,
	Jacob.e.keller@intel.com, kees@kernel.org, leon@kernel.org,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	mbloch@nvidia.com, mfleming@cloudflare.com,
	almasrymina@google.com, razor@blackwall.org, saeedm@nvidia.com,
	shivajikant@google.com, horms@kernel.org, sdf@fomichev.me,
	sdf.kernel@gmail.com, witu@nvidia.com, yuehaibing@huawei.com,
	bobbyeshleman@gmail.com
Subject: Re: [PATCH net-next 06/10] net/mlx5e: Add data direct TX infrastructure
Date: Mon, 12 Oct 2026 14:42:11 +0000	[thread overview]
Message-ID: <179181613153.434549.5589230692687372457@kernel.org> (raw)
In-Reply-To: <20261008132815.654147-7-tariqt@nvidia.com>

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

  reply	other threads:[~2026-10-12 14:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 13:28 [PATCH net-next 00/10] net/mlx5e: Add netdev support for data direct Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 01/10] net/mlx5: Log the data direct to PF device mapping Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 02/10] net/mlx5e: Register supported netdevs as data direct users Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 03/10] net/mlx5e: Pre-calculate UMR padding and entry size Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 04/10] net/mlx5e: Add data direct ethtool private flag Tariq Toukan
2026-10-08 13:28 ` [PATCH net-next 05/10] net/mlx5e: Add data direct RX infrastructure Tariq Toukan
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 06/10] net/mlx5e: Add data direct TX infrastructure Tariq Toukan
2026-10-12 14:42   ` netdev-bot+sashiko [this message]
2026-10-08 13:28 ` [PATCH net-next 07/10] net/mlx5e: Use the correct DMA dev when data_direct pdev enabled Tariq Toukan
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 08/10] net/mlx5e: Recreate netdev channels on data direct device unbind Tariq Toukan
2026-10-09 23:56   ` Mina Almasry
2026-10-10 14:00     ` Dragos Tatulea
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 09/10] net: devmem: add netdev_has_dmabuf_binding() helper Tariq Toukan
2026-10-09 23:56   ` Mina Almasry
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-08 13:28 ` [PATCH net-next 10/10] net/mlx5e: Enable the data direct netdev feature Tariq Toukan
2026-10-09 23:56   ` Mina Almasry
2026-10-12 14:42   ` netdev-bot+sashiko
2026-10-09 16:42 ` [PATCH net-next 00/10] net/mlx5e: Add netdev support for data direct Mina Almasry
2026-10-09 23:54   ` Mina Almasry
2026-10-10 14:16     ` Dragos Tatulea
2026-10-11 16:25       ` Mina Almasry
2026-10-11 18:54         ` Dragos Tatulea
2026-10-11 13:54     ` Tariq Toukan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179181613153.434549.5589230692687372457@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=Jacob.e.keller@intel.com \
    --cc=almasrymina@google.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bobbyeshleman@gmail.com \
    --cc=bobbyeshleman@meta.com \
    --cc=byungchul@sk.com \
    --cc=cjubran@nvidia.com \
    --cc=cratiu@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=dtatulea@nvidia.com \
    --cc=edumazet@kernel.org \
    --cc=gal@nvidia.com \
    --cc=horms@kernel.org \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mbloch@nvidia.com \
    --cc=mfleming@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    --cc=saeedm@nvidia.com \
    --cc=sdf.kernel@gmail.com \
    --cc=sdf@fomichev.me \
    --cc=shivajikant@google.com \
    --cc=tariqt@nvidia.com \
    --cc=witu@nvidia.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®