Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tariq Toukan" <tariqt@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next V2 11/13] net: add netdev_unbind_dma_dev() helper
Date: Wed, 11 Nov 2026 18:40:37 +0000	[thread overview]
Message-ID: <sashiko-outbox-209479@kernel.org> (raw)
In-Reply-To: <20261110183826.2927274-12-tariqt@nvidia.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] net: unmapping TX dmabufs on detached netdev in
  netdev_unbind_dma_dev()
- [Medium] net: race between netdev_unbind_dma_dev() and
  io_close_queue()
--

commit 3c773dc0f4402c3fc717479371e244f710ce138c
Author: Dragos Tatulea <dtatulea@nvidia.com>

net: add netdev_unbind_dma_dev() helper

This commit adds netdev_unbind_dma_dev() and net_devmem_unbind_dma_dev() to
uninstall RX memory providers and unmap TX devmem bindings associated with a
departing DMA device on a closed or detached netdev.

> diff --git a/net/core/netdev_queues.c b/net/core/netdev_queues.c
> index 27cb6397bdd4e..71cc7bfc087dd 100644
> --- a/net/core/netdev_queues.c
> +++ b/net/core/netdev_queues.c
[ ... ]
> +int netdev_unbind_dma_dev(struct net_device *dev, struct device *dma_dev)
> +{
> +	unsigned int i;
> +
> +	netdev_assert_locked(dev);
> +
> +	if (netif_running(dev) && netif_device_present(dev))
> +		return -EBUSY;

[Severity: High]
Can allowing netdev_unbind_dma_dev() on a running, detached netdev leave
validated devmem TX skbs queued in q->gso_skb after their dmabuf binding is
unmapped?

Unlike closing a netdev, netif_device_detach() only clears
__LINK_STATE_PRESENT and stops the TX queues without calling
dev_deactivate() or resetting q->gso_skb.  Any devmem TX skb that was
already validated by validate_xmit_unreadable_skb() and requeued onto
q->gso_skb when the queue stopped stays there while
net_devmem_unbind_dma_dev() unmaps the binding and clears binding->dev.

When netif_device_attach() later wakes the queues, dequeue_skb() pulls the
skb from q->gso_skb with *validate = false:

net/sched/sch_generic.c:dequeue_skb() {
    ...
		/* skb in gso_skb were already validated */
		*validate = false;
		if (xfrm_offload(skb))
			*validate = true;
		/* check the reason of requeuing without tx lock first */
		txq = skb_cap_tx_queue(q, skb);
		if (!netif_xmit_frozen_or_stopped(txq)) {
			skb = __skb_dequeue(&q->gso_skb);
    ...
}

sch_direct_xmit() then skips validate_xmit_skb_list() and passes the skb
with unmapped DMA addresses to ndo_start_xmit(), causing DMA to unmapped
memory or IOMMU faults.

> +
> +	for (i = 0; i < dev->real_num_rx_queues; i++) {
> +		struct netdev_rx_queue *rxq = __netif_get_rx_queue(dev, i);
> +		struct pp_memory_provider_params p = rxq->mp_params;
> +		struct device *queue_dev;
> +
> +		if (!p.mp_ops)
> +			continue;
> +
> +		queue_dev = __netdev_queue_get_dma_dev(dev, i);
> +		if (queue_dev && queue_dev != dma_dev)
> +			continue;
> +
> +		if (WARN_ON_ONCE(rxq->lease))
> +			continue;
> +
> +		memset(&rxq->mp_params, 0, sizeof(rxq->mp_params));
> +		__netif_mp_uninstall_rxq(rxq, &p);

[Severity: Medium]
Can this trigger the WARN_ON_ONCE() in __netif_mp_close_rxq() when racing
with io_close_queue()?

CPU0                                  CPU1
io_close_queue()
  mutex_lock(&ifq->pp_lock)
  netdev = ifq->netdev
  ifq->netdev = NULL
  mutex_unlock(&ifq->pp_lock)
                                      netdev_lock(netdev)
                                      netdev_unbind_dma_dev()
                                        memset(&rxq->mp_params, 0, ...)
                                        __netif_mp_uninstall_rxq()
                                          io_pp_uninstall()
                                            io_zcrx_drop_netdev()
                                      netdev_unlock(netdev)
  netdev_lock(netdev)
  if (ifq->if_rxq != -1)
    netif_mp_close_rxq()
      __netif_mp_close_rxq()
        WARN_ON_ONCE(...)  <-- hits warning

io_close_queue() clears ifq->netdev and drops ifq->pp_lock before taking
netdev_lock(netdev).  If netdev_unbind_dma_dev() runs in that window,
io_zcrx_drop_netdev() sees ifq->netdev == NULL and leaves ifq->if_rxq
unchanged, so io_close_queue() proceeds to call netif_mp_close_rxq().

In __netif_mp_close_rxq(), a cleared rxq->mp_params is only ignored when
dev->reg_state > NETREG_REGISTERED:

net/core/netdev_rx_queue.c:__netif_mp_close_rxq() {
    ...
	if (dev->reg_state > NETREG_REGISTERED &&
	    !rxq->mp_params.mp_ops)
		return 0;

	if (WARN_ON_ONCE(rxq->mp_params.mp_ops != old_p->mp_ops ||
			 rxq->mp_params.mp_priv != old_p->mp_priv))
		return -EINVAL;
    ...
}

Because netdev_unbind_dma_dev() runs while dev->reg_state is still
NETREG_REGISTERED, __netif_mp_close_rxq() hits the WARN_ON_ONCE().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110183826.2927274-1-tariqt@nvidia.com?part=11

  reply	other threads:[~2026-11-11 18:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 18:38 [PATCH net-next V2 00/13] net/mlx5e: Add netdev support for data direct Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 01/13] net/mlx5: Log the data direct to PF device mapping Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 02/13] net/mlx5: Detach auxiliary devices on attach failure during load Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 03/13] net/mlx5e: Register supported netdevs as data direct users Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 04/13] net/mlx5e: Pre-calculate UMR padding and entry size Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 05/13] net/mlx5e: Add data direct ethtool private flag Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 06/13] net/mlx5e: Add data direct RX infrastructure Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 07/13] net/mlx5e: SHAMPO, Use page_pool DMA sync helper for SKB frags Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 08/13] net/mlx5e: Add data direct TX infrastructure Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 09/13] net/mlx5e: Use the correct DMA dev when data_direct is enabled Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 10/13] net: devmem: add netdev_has_dmabuf_binding() helper Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-11 21:46   ` Stanislav Fomichev
2026-11-10 18:38 ` [PATCH net-next V2 11/13] net: add netdev_unbind_dma_dev() helper Tariq Toukan
2026-11-11 18:40   ` sashiko-bot [this message]
2026-11-10 18:38 ` [PATCH net-next V2 12/13] net/mlx5e: Disable data direct on data direct device unbind Tariq Toukan
2026-11-11 18:40   ` sashiko-bot
2026-11-10 18:38 ` [PATCH net-next V2 13/13] net/mlx5e: Enable the data direct netdev feature Tariq Toukan
2026-11-11 18:40   ` sashiko-bot

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=sashiko-outbox-209479@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tariqt@nvidia.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