From: Li Li <boolli@google.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny <decot@google.com>,
Anjali Singhai <anjali.singhai@intel.com>,
Sridhar Samudrala <sridhar.samudrala@intel.com>,
Brian Vazquez <brianvv@google.com>, Li Li <boolli@google.com>,
emil.s.tantilov@intel.com
Subject: [PATCH 2/5] idpf: skip changing MTU if vport is NULL during HW reset
Date: Wed, 7 Jan 2026 01:05:00 +0000 [thread overview]
Message-ID: <20260107010503.2242163-2-boolli@google.com> (raw)
In-Reply-To: <20260107010503.2242163-1-boolli@google.com>
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 userspace changes the MTU of the netdev,
the vport associated with the netdev is NULL, and so a kernel panic
would happen:
[ 2081.955742] BUG: kernel NULL pointer dereference, address: 0000000000000068
...
[ 2082.002739] RIP: 0010:idpf_initiate_soft_reset+0x19/0x190
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 changing the MTU of the netdev in
userspace.
With this patch applied, we see the following error but no kernel
panics anymore:
[ 304.291346] idpf 0000:05:00.0 eth1: mtu not changed due to no vport innetdev
RTNETLINK answers: Bad address
Signed-off-by: Li Li <boolli@google.com>
---
drivers/net/ethernet/intel/idpf/idpf_lib.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c
index 57b8b3fd9124c..53b31989722a7 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
@@ -2328,11 +2327,17 @@ static int idpf_change_mtu(struct net_device *netdev, int new_mtu)
idpf_vport_ctrl_lock(netdev);
vport = idpf_netdev_to_vport(netdev);
+ if (!vport) {
+ netdev_err(netdev, "mtu not changed due to no vport in netdev\n");
+ err = -EFAULT;
+ goto unlock;
+ }
WRITE_ONCE(netdev->mtu, new_mtu);
err = idpf_initiate_soft_reset(vport, IDPF_SR_MTU_CHANGE);
+unlock:
idpf_vport_ctrl_unlock(netdev);
return err;
--
2.52.0.351.gbe84eed79e-goog
next prev parent reply other threads:[~2026-01-07 1:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 1:04 [PATCH 1/5] idpf: skip getting/setting ring params if vport is NULL during HW reset Li Li
2026-01-07 1:05 ` Li Li [this message]
2026-01-07 1:05 ` [PATCH 3/5] idpf: skip getting RX flow rules " Li Li
2026-01-12 9:58 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-07 1:05 ` [PATCH 4/5] idpf: skip setting channels " Li Li
2026-01-07 1:05 ` [PATCH 5/5] idpf: skip stopping/opening vport if it " Li Li
2026-01-09 6:06 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-01-09 6:10 ` Loktionov, Aleksandr
2026-01-07 5:30 ` [Intel-wired-lan] [PATCH 1/5] idpf: skip getting/setting ring params if vport " Paul Menzel
2026-01-07 18:39 ` Li Li
2026-01-07 17:41 ` Tantilov, Emil S
2026-01-07 18:40 ` Li Li
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=20260107010503.2242163-2-boolli@google.com \
--to=boolli@google.com \
--cc=anjali.singhai@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=brianvv@google.com \
--cc=davem@davemloft.net \
--cc=decot@google.com \
--cc=edumazet@google.com \
--cc=emil.s.tantilov@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=sridhar.samudrala@intel.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