All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Koichiro Den" <den@valinux.co.jp>
Cc: ntb@lists.linux.dev
Subject: Re: [PATCH net] net: ntb_netdev: Fix statistics races
Date: Tue, 25 Aug 2026 02:57:39 +0000	[thread overview]
Message-ID: <20260825025740.5AF271F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260824025720.3520288-1-den@valinux.co.jp>

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

Pre-existing issues:
- [High] Pending RX and TX entries are leaked because their associated SKB buffers are not freed when the transport queue is destroyed.
--

--- Patch [1]: [PATCH net] net: ntb_netdev: Fix statistics races ---
commit fc558d0a991ec95505df001446270417159e2eaf
Author: Koichiro Den <den@valinux.co.jp>

net: ntb_netdev: Fix statistics races

ntb_netdev updates shared net_device stats from per-QP RX and TX callbacks.
This commit shifts the driver to use core-managed per-CPU dstats. It also
tears down transport queues from ndo_uninit before the core frees dstats.

> diff --git a/drivers/net/ntb_netdev.c b/drivers/net/ntb_netdev.c
> index 9c171697e7620..6a1e58d5d7d67 100644
> --- a/drivers/net/ntb_netdev.c
> +++ b/drivers/net/ntb_netdev.c
[ ... ]
> @@ -427,7 +428,19 @@ static int ntb_netdev_change_mtu(struct net_device *ndev, int new_mtu)
>  	return rc;
>  }
>  
> +static void ntb_netdev_uninit(struct net_device *ndev)
> +{
> +	struct ntb_netdev *dev = netdev_priv(ndev);
> +	unsigned int q;
> +
> +	for (q = 0; q < dev->num_queues; q++) {
> +		ntb_transport_free_queue(dev->queues[q].qp);

[Severity: High]
This is a pre-existing issue, but does calling ntb_transport_free_queue()
leak the SKBs attached to pending packets?

Looking at ntb_transport_free_queue() in drivers/ntb/ntb_transport.c,
it cleans up pending items from the queues like this:

drivers/ntb/ntb_transport.c:ntb_transport_free_queue() {
    ...
    while ((entry = ntb_list_rm(&qp->ntb_rx_q_lock, &qp->rx_post_q))) {
        dev_warn(&pdev->dev, "Freeing item from non-empty rx_post_q\n");
        kfree(entry);
    }
    ...
}

It frees the entry, but it doesn't seem to free or return the attached
client buffer (entry->cb_data). Since ntb_netdev uses cb_data to store
allocated SKBs, does this unconditionally leak any in-flight packets
when the queue is destroyed?

> +		dev->queues[q].qp = NULL;
> +	}
> +}
> +
>  static const struct net_device_ops ntb_netdev_ops = {
> +	.ndo_uninit = ntb_netdev_uninit,
>  	.ndo_open = ntb_netdev_open,
>  	.ndo_stop = ntb_netdev_close,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824025720.3520288-1-den@valinux.co.jp?part=1

  reply	other threads:[~2026-08-25  2:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  2:57 [PATCH net] net: ntb_netdev: Fix statistics races Koichiro Den
2026-08-25  2:57 ` sashiko-bot [this message]
2026-08-27 11:07   ` Simon Horman
2026-08-27 11:04 ` Simon Horman
2026-08-28  1:06   ` Koichiro Den

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=20260825025740.5AF271F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=den@valinux.co.jp \
    --cc=ntb@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.