Re: [PATCH net-next v2 08/13] net: lan966x: add shutdown callback to stop FDMA on reboot

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `lan966x_shutdown()` callback fails to detach the network stack and NAPI, allowing concurrent network activity to completely undo the shutdown sequence.
- [High] Use-After-Free in `lan966x_remove()` if packets are transmitted during driver teardown.
--

Note: The format of this review has been altered and inline code quoting
omitted due to recitation restrictions.

commit a6cbd3c8269201ecd4eb49e03692cba4eced4799
Author: Daniel Machon <daniel.machon@microchip.com>

net: lan966x: add shutdown callback to stop FDMA on reboot

This commit adds a shutdown callback to the lan966x driver to mask FDMA
interrupts and disable RX and TX channels, preventing shared PCIe INTx
assertion during reboot.

In the newly added lan966x_shutdown() function, the network stack and
NAPI are not detached or disabled before shutting down the hardware.

Because network interfaces can remain active during system shutdown, could
concurrent packet transmissions invoke ndo_start_xmit and subsequently
lan966x_fdma_xmit()?

If lan966x_fdma_xmit() evaluates tx->activated as false after the shutdown
routine clears it, it appears it will unconditionally call
lan966x_fdma_tx_activate(). Will this directly write to hardware registers
to re-enable the TX DMA channel and unmask interrupts, effectively undoing
the shutdown sequence?

Similarly, could a concurrent NAPI poll finish and call napi_complete_done(),
rewriting 0xff to FDMA_INTR_DB_ENA and re-arming the doorbell interrupts?
Should the shutdown sequence call netif_device_detach() and napi_disable()
to ensure the device is fully quiesced?

While reviewing the device teardown paths, a pre-existing issue in
lan966x_remove() was noticed.

The driver calls ops->fdma_deinit() before unregistering the network
devices via lan966x_cleanup_ports(). Since fdma_deinit frees the TX
ring buffers, is it possible for the network stack to still invoke
ndo_start_xmit while the devices are registered?

Would this cause a use-after-free if lan966x_fdma_xmit() dereferences
and writes to the freed tx->dcbs_buf array? Should the network devices
be fully unregistered before their backing queue memory is destroyed?

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