Hi Maxime,

On Mon Oct 05 2026, Maxime Chevallier wrote:
> On 10/5/26 09:09, Kurt Kanzenbach wrote:
>> Attaching an XDP program while Tx traffic is running results in kernel
>> crashes in stmmac_xmit() -> dwmac4_set_addr().
>> 
>> Loading an XDP program tears down and reallocates all DMA resources via
>> stmmac_xdp_release() and stmmac_xdp_open(). stmmac_xdp_release() stops
>> the Tx queues before disabling NAPI:
>> 
>>  stmmac_xdp_release:
>>    netif_tx_disable
>>    stmmac_disable_all_queues
>>    ...
>>    free_dma_desc_resources
>> 
>> A Tx NAPI poll may still be in flight at that point. stmmac_tx_clean()
>> takes the Tx queue lock, reaps completed descriptors and wakes the queue
>> again when it observes it stopped with enough descriptors available.
>> Nothing stops the queue afterwards, so the Tx path resumes while
>> free_dma_desc_resources() releases the descriptor rings underneath it.
>> 
>> On non-coherent platforms dma_free_coherent() tears down the vmalloc
>> mapping of the descriptors, so the subsequent stmmac_xmit() faults on an
>> unmapped address instead of corrupting memory silently.
>> 
>> Disable NAPI first and stop the Tx queues afterwards, which is the order
>> already used by __stmmac_release().
>> 
>> The issue can be easily reproduced by:
>> 
>>  1. Run iperf
>>  2. Run application which opens an AF_XDP/ZC socket
>> 
>> Assisted-by: Claude:claude-opus-5
>> Fixes: 77711683a504 ("net: stmmac: ensure tx function is not running in stmmac_xdp_release()")
>> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
>
> This now matches the non-xdp case, great :)

Thanks for the review! Yes, it does match now. We could also collapse
the common teardown code between __stmmac_release() and
stmmac_xdp_release() into a helper function now and reduce code
duplication.

Thanks,
Kurt