Re: [PATCH iwl-net 1/2] idpf: keep the mailbox up while tearing down vports on shutdown

["Tantilov, Emil S" <emil.s.tantilov@intel.com>]

On 9/17/2026 3:52 AM, Tian Xun Ng wrote:
> From: Tian Xun Ng <tianxun.ng@bytedance.com>
> 
> 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?

> 
> 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 <tianxun.ng@bytedance.com>
> ---
>   .../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?>
>   	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);