Re: [Intel-wired-lan] [PATCH 1/5] idpf: skip getting/setting ring params if vport is NULL during HW reset

Please reject this patch series given the underlying issue is fixed in
an earlier patch
series already, thanks.

On Wed, Jan 7, 2026 at 9:41 AM Tantilov, Emil S
[off-list ref] wrote:

On 1/6/2026 5:04 PM, Li Li via Intel-wired-lan wrote:

quoted

When an idpf HW reset is triggered, it clears the vport but does
not clear the netdev held by vport:

     // In idpf_vport_dealloc() called by idpf_init_hard_reset(),
     // idpf_init_hard_reset() sets IDPF_HR_RESET_IN_PROG, so
     // idpf_decfg_netdev() doesn't get called.
     if (!test_bit(IDPF_HR_RESET_IN_PROG, adapter->flags))
         idpf_decfg_netdev(vport);
     // idpf_decfg_netdev() would clear netdev but it isn't called:
     unregister_netdev(vport->netdev);
     free_netdev(vport->netdev);
     vport->netdev = NULL;
     // Later in idpf_init_hard_reset(), the vport is cleared:
     kfree(adapter->vports);
     adapter->vports = NULL;

During an idpf HW reset, when "ethtool -g/-G" is called on the netdev,
the vport associated with the netdev is NULL, and so a kernel panic
would happen:

[  513.185327] BUG: kernel NULL pointer dereference, address: 0000000000000038
...
[  513.232756] RIP: 0010:idpf_get_ringparam+0x45/0x80

This can be reproduced reliably by injecting a TX timeout to cause
an idpf HW reset, and injecting a virtchnl error to cause the HW
reset to fail and retry, while calling "ethtool -g/-G" on the netdev
at the same time.

I have posted series that resolves these issues in the reset path by
reshuffling the flow a bit and adding netif_device_detach/attach to
make sure the netdevs are better protected in the middle of a reset:
https://lore.kernel.org/intel-wired-lan/20251121001218.4565-1-emil.s.tantilov@intel.com/ (local)

If you are still seeing issues with the above applied, let me know and I
can take a look.

Thanks Emil! Yes I performed the experiment at a commit past your
patch series above, and it
does look like the kernel panic does appear anymore. Now performing
ethtool commands during
HW resets would result in "netlink error: No such device", which is
expected because we are detaching
the netdev at the start of the HW reset.

Please reject this patch series, thanks!

quoted

With this patch applied, we see the following error but no kernel
panics anymore:

[  476.323630] idpf 0000:05:00.0 eth1: failed to get ring params due to no vport in netdev

Signed-off-by: Li Li <redacted>
---
  drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 12 ++++++++++++
  1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
index d5711be0b8e69..6a4b630b786c2 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c

@@ -639,6 +638,10 @@ static void idpf_get_ringparam(struct net_device *netdev,

      idpf_vport_ctrl_lock(netdev);
      vport = idpf_netdev_to_vport(netdev);
+     if (!vport) {

We used to have these all over the place, but the code was changed to
rely on idpf_vport_ctrl_lock() for the protection of the vport state.
Still some issues remain with the error paths (hence the series above),
but in general we don't want to resort to vport NULL checks and rather
fix the reset flows to rely on cleaner logic and locks.

Thanks,
Emil

quoted

+             netdev_err(netdev, "failed to get ring params due to no vport in netdev\n");
+             goto unlock;
+     }

      ring->rx_max_pending = IDPF_MAX_RXQ_DESC;
      ring->tx_max_pending = IDPF_MAX_TXQ_DESC;

@@ -647,6 +651,7 @@ static void idpf_get_ringparam(struct net_device *netdev,

      kring->tcp_data_split = idpf_vport_get_hsplit(vport);

+unlock:
      idpf_vport_ctrl_unlock(netdev);
  }

@@ -673,6 +674,11 @@ static int idpf_set_ringparam(struct net_device *netdev,

      idpf_vport_ctrl_lock(netdev);
      vport = idpf_netdev_to_vport(netdev);
+     if (!vport) {
+             netdev_err(netdev, "ring params not changed due to no vport in netdev\n");
+             err = -EFAULT;
+             goto unlock_mutex;
+     }

      idx = vport->idx;