Re: [PATCH net-next v2 10/13] net: lan966x: add PCIe FDMA MTU change support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] NAPI is enabled after unmasking hardware interrupts, causing a race condition that permanently stalls the RX/TX queues.
--

commit 1f509ad580a86a49efbb1d85d8112806e4ae3d36
Author: Daniel Machon <daniel.machon@microchip.com>
net: lan966x: add PCIe FDMA MTU change support

This commit adds MTU change support for the PCIe FDMA path. When the MTU
changes, contiguous ATU-mapped RX and TX buffers are reallocated with the
new size, or restored to the old ones on failure.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index bda9679a03e1..61a62dbcc313 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
[ ... ]
> @@ -306,9 +311,154 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)
>  	return 0;
>  }
>  
[ ... ]
> +static int lan966x_fdma_pci_reload(struct lan966x *lan966x, int new_mtu)
> +{
[ ... ]
> +	/* Free and unmap old memory. */
> +	fdma_free_coherent_and_unmap(lan966x->dev, &rx_fdma_old);
> +	fdma_free_coherent_and_unmap(lan966x->dev, &tx_fdma_old);
> +
> +	lan966x_fdma_rx_start(&lan966x->rx);
> +	lan966x_fdma_pci_wakeup_netdev(lan966x);
> +	napi_enable(&lan966x->napi);

Is there a race condition here between unmasking the hardware interrupts and
enabling NAPI?

lan966x_fdma_rx_start() unmasks hardware interrupts for the RX channel. If an
interrupt fires immediately after this call but before napi_enable() executes,
the IRQ handler will run, mask the interrupt in hardware, and call
napi_schedule().

Because napi_enable() hasn't been called yet, the NAPI state is still
disabled, so napi_schedule_prep() will fail and NAPI won't be scheduled. Once
napi_enable() finally runs, the poll schedule is already lost and the hardware
interrupt remains permanently masked, stalling the queues.

Should napi_enable() be called before lan966x_fdma_rx_start() to ensure any
immediate interrupts are properly scheduled?

> +
> +	return err;
> +restore:
> +
> +	/* No new buffers are allocated at this point. Use the old buffers,
> +	 * but reset them before starting the FDMA again.
> +	 */
> +
> +	memcpy(&lan966x->tx.fdma, &tx_fdma_old, sizeof(struct fdma));
> +	memcpy(&lan966x->rx.fdma, &rx_fdma_old, sizeof(struct fdma));
> +
> +	lan966x->rx.max_mtu = old_mtu;
> +
> +	lan966x_fdma_pci_reset_mem(lan966x);
> +
> +	lan966x_fdma_rx_start(&lan966x->rx);
> +	lan966x_fdma_pci_wakeup_netdev(lan966x);
> +	napi_enable(&lan966x->napi);

This same sequence appears here in the restore path. Does it have the same
potential issue with missed interrupts?

> +
> +	return err;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260428-lan966x-pci-fdma-v2-0-d3ec66e06202@microchip.com?part=10