Re: [PATCH iwl-net 1/2] idpf: keep the mailbox up while tearing down vports on shutdown
From: Tantilov, Emil S <hidden>
Date: 2026-09-18 17:59:52
Also in:
intel-wired-lan
On 9/17/2026 3:52 AM, Tian Xun Ng wrote:
From: Tian Xun Ng <redacted>
Since commit 4c9106f4906a ("idpf: fix adapter NULL pointer dereference
on reboot"), idpf_shutdown() calls idpf_vc_core_deinit() directly instead
of idpf_remove(), so IDPF_REMOVE_IN_PROG is not set on shutdown.
idpf_vc_core_deinit() uses that flag to decide when to shut the virtchnl
transaction manager down. Without it, libie_ctlq_xn_shutdown() runs
before idpf_deinit_task() tears the vports down, so every message sent
during that teardown (disable vport, disable queues, destroy vport)
fails at once. The device is never told to stop its queues and keeps
them enabled, with the ring addresses of the kernel that is going away.
After a warm reboot, the first queue reconfiguration of a port that has
not been opened yet (udev setting the MTU) sends VIRTCHNL2_OP_DEL_QUEUES.
The device then drains the queues it still considers live and writes
SW_MARKER TX completions (qid_comptype_gen 0x2800 / 0xa800) to the
previous kernel's completion rings. With the IOMMU translating, those
writes fault on every such boot:
arm-smmu-v3 arm-smmu-v3.17.auto: event: F_TRANSLATION client: 0016:01:00.0 sid: 0x30100 ssid: 0x0 iova: 0xffb70000 ipa: 0x0
arm-smmu-v3 arm-smmu-v3.17.auto: unpriv data write s1 "Input address caused fault" stag: 0x0
In IOMMU pass-through mode they land on pages the new kernel has already
reused. With page_poison=1 that shows as "pagealloc: memory corruption"
on most boots. Without it, nodes crash in unrelated code, e.g.:
Unable to handle kernel NULL pointer dereference at virtual address 000000000000a830
pc : __tlb_remove_table_free+0x48/0x118
Call trace:
__tlb_remove_table_free
tlb_remove_table_rcu
rcu_do_batch
or with a slab free pointer that decodes from a slot holding 0x2800:
Unable to handle kernel paging request at virtual address 002613b73e862c6e
pc : kmem_cache_alloc_noprof+0xc0/0x3d0
The early shutdown exists to avoid waiting for transaction timeouts when
the mailbox is already gone. That is the hard reset case, where
idpf_vc_event_task() shuts the transaction manager down and sets
IDPF_HR_RESET_IN_PROG before idpf_init_hard_reset() calls
idpf_vc_core_deinit(). Key the early shutdown on a hard reset being in
progress or detected instead of on remove, so that both remove and
shutdown keep the mailbox up until the vports are gone.
Hard reset behaviour is unchanged. Remove is unchanged unless a hardware
reset has been detected, in which case it no longer waits for message
timeouts. Shutdown now delivers the teardown messages; if the device
stops responding without a detectable reset, shutdown can wait for the
transaction timeouts, as remove already does.Actually we can't wait on shutdown. If the MBX is defunct, like CP is down or unresponsive, the shutdown will hang for a very long time. This is the reason why we wanted to avoid communication on shutdown. Have you tested the shutdown after stopping the control plane?
quoted hunk ↗ jump to hunk
Tested on arm64 (64K pages) servers with two idpf functions, with this change and the next patch backported to a 6.17 kernel: no stray device writes in 151 warm reboots across IOMMU translated and pass-through modes, against stray writes after 20 of 20 warm reboots without them. Fixes: 4c9106f4906a ("idpf: fix adapter NULL pointer dereference on reboot") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Tian Xun Ng <redacted> --- .../net/ethernet/intel/idpf/idpf_virtchnl.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c index 1caf52706..646b6e074 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c@@ -3197,14 +3197,22 @@ int idpf_vc_core_init(struct idpf_adapter *adapter) */ void idpf_vc_core_deinit(struct idpf_adapter *adapter) { - bool remove_in_prog; + bool reset_in_prog; if (!test_bit(IDPF_VC_CORE_INIT, adapter->flags)) return; - /* Avoid transaction timeouts when called during reset */ - remove_in_prog = test_bit(IDPF_REMOVE_IN_PROG, adapter->flags); - if (!remove_in_prog) + /* Shut the transaction manager down early only when the mailbox is + * already gone, i.e. a hard reset is in progress or has been detected, + * to avoid waiting for transaction timeouts. On remove and on shutdown + * the mailbox still works and must stay up until the vports are torn + * down. Otherwise the disable and destroy messages never reach the + * device, which keeps its queues enabled with ring addresses from this + * kernel after a warm reboot. + */ + reset_in_prog = test_bit(IDPF_HR_RESET_IN_PROG, adapter->flags) || + idpf_is_reset_detected(adapter); + if (reset_in_prog) libie_ctlq_xn_shutdown(adapter->xnm);
This logic already exists in the reset handling, there should be no need to replicate it here. Do you have a trace and/or exact scenario that leads to remove being called while in a reset, but MBX is still alive?>
quoted hunk ↗ jump to hunk
idpf_ptp_release(adapter);@@ -3213,7 +3221,7 @@ void idpf_vc_core_deinit(struct idpf_adapter *adapter) idpf_rel_rx_pt_lkup(adapter); idpf_intr_rel(adapter); - if (remove_in_prog) + if (!reset_in_prog) libie_ctlq_xn_shutdown(adapter->xnm); cancel_delayed_work_sync(&adapter->serv_task);