Netdev List
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: mengyuanlou@net-swift.com
Cc: netdev@vger.kernel.org, jiawenwu@trustnetic.com,
	duanqiangwen@net-swift.com, horms@kernel.org, kuba@kernel.org,
	pabeni@redhat.com
Subject: Re: [PATCH net-next v6 3/3] net: libwx: support vf per-queue statistics via ethtool -S
Date: Tue,  7 Jul 2026 11:50:46 +0200	[thread overview]
Message-ID: <20260707095046.104606-1-pabeni@redhat.com> (raw)
In-Reply-To: <20260701100145.23738-4-mengyuanlou@net-swift.com>

From: AI Reviewer <ai@example.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
Now I have enough information to produce the report.

commit e59c58bb080afb34cac34c91b8c320a1f05134e6
Author: Mengyuan Lou <mengyuanlou@net-swift.com>

net: libwx: support vf per-queue statistics via ethtool -S

The patch wires wx_get_sset_count, wx_get_strings, and wx_get_ethtool_stats
into wx_ethtool_ops_vf, adds a small vf-only global stats table, and starts
calling wx_update_stats() from wxvf_service_task. It also adds NULL checks
for wx->rx_ring[i] / wx->tx_ring[i] inside wx_update_stats.

> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c b/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c
> index 22037f015ded..f72908630ea4 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_ethtool.c

[ ... ]

> @@ -114,7 +133,7 @@ void wx_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
>  			ethtool_sprintf(&p, "tx_queue_%u_packets", i);
>  			ethtool_sprintf(&p, "tx_queue_%u_bytes", i);
>  		}
> -		for (i = 0; i < WX_NUM_RX_QUEUES; i++) {
> +		for (i = 0; i < WX_NUM_RX_QUEUES(netdev); i++) {
>  			ethtool_sprintf(&p, "rx_queue_%u_packets", i);
>  			ethtool_sprintf(&p, "rx_queue_%u_bytes", i);
>  		}

[ ... ]

> @@ -852,6 +878,9 @@ static const struct ethtool_ops wx_ethtool_ops_vf = {
>  	.set_coalesce		= wx_set_coalesce,
>  	.get_ts_info		= ethtool_op_get_ts_info,
>  	.get_link_ksettings	= wx_get_link_ksettings_vf,
> +	.get_sset_count		= wx_get_sset_count,
> +	.get_strings		= wx_get_strings,
> +	.get_ethtool_stats	= wx_get_ethtool_stats,
>  };

[Medium]
Before this change wx_ethtool_ops_vf had no get_sset_count / get_strings /
get_ethtool_stats callbacks, so the VF exposed no ethtool -S output at all.
Wiring these in also picks up the shared per-queue string loop that emits
tx_queue_%u_packets / tx_queue_%u_bytes and rx_queue_%u_packets /
rx_queue_%u_bytes.

Per-queue TX/RX packet and byte counters are a category that already has a
standard uAPI (netdev_stat_ops with queue_stats_rx / queue_stats_tx,
surfaced by netlink and ynl). Documentation/networking/statistics.rst and
the ethtool -S guidance state that new counters covering values that have a
standard uAPI should not be added to ethtool -S even when the driver does
not yet implement the standard interface.

The wangxun tree does not implement netdev_stat_ops (no
get_base_stats / get_queue_stats_rx / get_queue_stats_tx callbacks are
present under drivers/net/ethernet/wangxun/).

Would it be preferable to expose the per-queue counters on the VF via
netdev_stat_ops instead of adding them to ethtool -S here?

>  void wx_set_ethtool_ops_vf(struct net_device *netdev)
> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_hw.c b/drivers/net/ethernet/wangxun/libwx/wx_hw.c
> index 260e14d5d541..349afbe60132 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_hw.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_hw.c
> @@ -2886,6 +2886,8 @@ void wx_update_stats(struct wx *wx)
>  	for (i = 0; i < wx->num_rx_queues; i++) {
>  		struct wx_ring *rx_ring = wx->rx_ring[i];
>  
> +		if (!rx_ring)
> +			continue;
>  		non_eop_descs += rx_ring->rx_stats.non_eop_descs;

[ ... ]

> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_vf_common.c b/drivers/net/ethernet/wangxun/libwx/wx_vf_common.c
> index 26de78e9a69e..1d84fe35d7d9 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_vf_common.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_vf_common.c
> @@ -409,6 +410,7 @@ static void wxvf_service_task(struct work_struct *work)
>  
>  	wxvf_link_config_subtask(wx);
>  	wxvf_reset_subtask(wx);
> +	wx_update_stats(wx);
>  	wx_service_event_complete(wx);
>  }

[High]
Can this call race with VF PCI suspend and shutdown to produce a
use-after-free on wx->rx_ring[i] / wx->tx_ring[i]?

Both ngbevf and txgbevf use wxvf_suspend as their PM suspend callback and
wxvf_shutdown (which calls wxvf_suspend) as their pci_driver ->shutdown
callback:

    static DEFINE_SIMPLE_DEV_PM_OPS(ngbevf_pm_ops, wxvf_suspend, wxvf_resume);
    ...
    .shutdown = wxvf_shutdown,

wxvf_suspend() in wx_vf_common.c does:

    int wxvf_suspend(struct device *dev_d)
    {
        struct pci_dev *pdev = to_pci_dev(dev_d);
        struct wx *wx = pci_get_drvdata(pdev);

        netif_device_detach(wx->netdev);
        wx_clear_interrupt_scheme(wx);
        pci_disable_device(pdev);

        return 0;
    }

wx_clear_interrupt_scheme() ends up freeing the q_vectors (via
kfree_rcu), and the ring allocations are embedded in the q_vector, so
wx->rx_ring[i] / wx->tx_ring[i] end up pointing at memory that will be
freed after an RCU grace period.

wxvf_suspend / wxvf_shutdown do not call timer_shutdown_sync on
wx->service_timer or cancel_work_sync on wx->service_task, and they do
not set WX_STATE_DOWN.

With this hunk in place, the service_task now walks wx->rx_ring[] and
wx->tx_ring[]:

    void wx_update_stats(struct wx *wx)
    {
        ...
        for (i = 0; i < wx->num_rx_queues; i++) {
            struct wx_ring *rx_ring = wx->rx_ring[i];

            if (!rx_ring)
                continue;
            non_eop_descs += rx_ring->rx_stats.non_eop_descs;
            ...
        }
        ...
        for (i = 0; i < wx->num_tx_queues; i++) {
            struct wx_ring *tx_ring = wx->tx_ring[i];

            if (!tx_ring)
                continue;
            restart_queue += tx_ring->tx_stats.restart_queue;
            ...
        }

If the service_task latches a non-NULL rx_ring / tx_ring pointer just
before wx_clear_interrupt_scheme runs, the added NULL check does not
help, and the subsequent ->rx_stats / ->tx_stats reads touch memory
that has been kfree_rcu'd. wxvf_remove() covers this by calling
timer_shutdown_sync + cancel_work_sync before wx_clear_interrupt_scheme,
but wxvf_suspend / wxvf_shutdown do not.

Should wxvf_suspend (and hence wxvf_shutdown) quiesce the service_timer
and service_task, or set WX_STATE_DOWN, before wx_clear_interrupt_scheme
now that wx_update_stats is on the service_task's call path?
-- 
This is an AI-generated review.


  reply	other threads:[~2026-07-07  9:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 10:01 [PATCH net-next v6 0/3] net: libwx: improve VF ethtool support Mengyuan Lou
2026-07-01 10:01 ` [PATCH net-next v6 1/3] net: libwx: add support for set_ringparam in wx_ethtool_ops_vf Mengyuan Lou
2026-07-01 10:01 ` [PATCH net-next v6 2/3] net: libwx: add support for set_coalesce " Mengyuan Lou
2026-07-01 10:01 ` [PATCH net-next v6 3/3] net: libwx: support vf per-queue statistics via ethtool -S Mengyuan Lou
2026-07-07  9:50   ` Paolo Abeni [this message]
2026-07-08 10:23     ` mengyuanlou

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=20260707095046.104606-1-pabeni@redhat.com \
    --to=pabeni@redhat.com \
    --cc=duanqiangwen@net-swift.com \
    --cc=horms@kernel.org \
    --cc=jiawenwu@trustnetic.com \
    --cc=kuba@kernel.org \
    --cc=mengyuanlou@net-swift.com \
    --cc=netdev@vger.kernel.org \
    /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