Re: [PATCH net-next 13/15] net: enetc: dynamically allocate rxmsg based on VF count

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Teardown race leading to a permanent infinite loop in the msg_task workqueue.
- [High] Uninitialized work struct race in enetc_msg_psi_init causes workqueue list corruption.
--

commit 2a9ca5a7c76f884ea46d71ecd971d43269b7a246
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: dynamically allocate rxmsg based on VF count

To better match hardware capabilities and avoid unnecessary memory usage,
this patch changes rxmsg memory allocation from a fixed-size array to
dynamic allocation based on the actual VF count.

[ ... ]

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.h b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
> index 9fcf1c58d59b4..d4f1041587f7a 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.h
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.h
> @@ -42,7 +42,7 @@ struct enetc_pf {
>  
>  	struct enetc_mac_filter mac_filter[MADDR_TYPE];
>  
> -	struct enetc_msg_swbd rxmsg[ENETC_MAX_NUM_VFS];
> +	struct enetc_msg_swbd *rxmsg;
>  	struct work_struct msg_task;

This problem wasn't introduced by this patch, but I noticed a potential
teardown race involving msg_task.

In enetc_msg_psi_free(), cancel_work_sync(&pf->msg_task) is called before
free_irq(). If an MR interrupt is delivered immediately after
cancel_work_sync() returns, the ISR (enetc_msg_psi_msix) could execute and
re-queue the work via schedule_work().

Subsequently, enetc_sriov_configure() sets pf->num_vfs = 0.

When the improperly scheduled msg_task eventually executes, it reads a
non-zero mr_mask from the hardware. However, because pf->num_vfs is now 0,
the inner for (i = 0; i < pf->num_vfs; i++) loop is skipped. Consequently,
the hardware's write-1-to-clear (w1c) register is never written to clear the
interrupt status.

Could this cause the outer for (;;) loop to read the exact same non-zero
mr_mask on every iteration, spinning in a permanent infinite loop and
stalling the workqueue?

Furthermore, in the error path of enetc_msg_psi_init(), cancel_work_sync() is
missing entirely. Could this lead to the exact same infinite loop if an
interrupt fired prior to the failure?

Also related to msg_task, in enetc_msg_psi_init(), request_irq() is called to
register the interrupt handler enetc_msg_psi_msix before
INIT_WORK(&pf->msg_task, enetc_msg_task) initializes the work structure.

If the hardware asserts an interrupt from a previous boot or kexec state, or
if a spurious interrupt occurs, the ISR will execute immediately upon
registration and call schedule_work(&pf->msg_task) on an uninitialized,
zero-filled work_struct.

Could this cause list corruption and crash the kernel's workqueue subsystem
because the internal list pointers are NULL? Should INIT_WORK() always be
called before request_irq()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511080805.2052495-1-wei.fang@nxp.com?part=13