Re: [PATCH net-next v9 12/15] 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] net: lan966x: race condition between fdma_pci_init and mtu resize
--

commit 729515bac2cb6bfa764aa18fa01ab2ab548fd6be
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. On an mtu
change, the rx and tx buffers are reallocated to the new size. It also caps
the PCIe DCB ring size and defers resizing until initialization has built
the rings.

> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> index f511e70613141..758554c951c52 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma_pci.c

[ ... ]

> @@ -428,9 +428,156 @@ static int lan966x_fdma_pci_init(struct lan966x *lan966x)

[ ... ]

> +static int lan966x_fdma_pci_resize(struct lan966x *lan966x)
> +{
> +	int max_mtu;
> +
> +	/* Nothing to resize until fdma_pci_init() has built the rings; it
> +	 * sizes them from DEV_MAC_MAXLEN_CFG, which the caller already set.
> +	 */
> +	if (!lan966x->rx.lan966x)
> +		return 0;

[Severity: High]
Does this initialization guard safely prevent concurrent execution with
the driver probe?

In lan966x_fdma_pci_init(), the rx.lan966x pointer is assigned before the
actual memory allocations are completed:

lan966x_fdma_pci_init() {
        ...
        lan966x->rx.lan966x = lan966x;
        ...
        err = lan966x_fdma_pci_rx_alloc(&lan966x->rx);
        ...
}

Since the network device is registered and accessible before the probe
thread finishes calling lan966x_fdma_pci_init(), could a concurrent mtu
change via netlink pass the guard here while the rings are only partially
initialized?

If this race occurs, the reload operation might attempt to free
uninitialized or null memory via dma_free_coherent(), leading to potential
memory leaks, data races on dma structures, or a kernel panic.

> +
> +	max_mtu = lan966x_fdma_get_max_frame(lan966x);
> +	if (max_mtu == lan966x->rx.max_mtu)
> +		return 0;
> +
> +	return __lan966x_fdma_pci_reload(lan966x, max_mtu);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-lan966x-pci-fdma-v9-0-a17caf60f89a@microchip.com?part=12