Re: [v3 PATCH net] net: enetc: fix the deadlock of enetc_mdio_lock

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Fri, Oct 10, 2025 at 12:31:37PM +0300, Wei Fang wrote:
> > After applying the workaround for err050089, the LS1028A platform
> > experiences RCU stalls on RT kernel. This issue is caused by the
> > recursive acquisition of the read lock enetc_mdio_lock. Here list some
> > of the call stacks identified under the enetc_poll path that may lead to
> > a deadlock:
> > 
> > enetc_poll
> >   -> enetc_lock_mdio
> >   -> enetc_clean_rx_ring OR napi_complete_done
> >      -> napi_gro_receive
> >         -> enetc_start_xmit
> >            -> enetc_lock_mdio
> >            -> enetc_map_tx_buffs
> >            -> enetc_unlock_mdio
> >   -> enetc_unlock_mdio
> > 
> > After enetc_poll acquires the read lock, a higher-priority writer attempts
> > to acquire the lock, causing preemption. The writer detects that a
> > read lock is already held and is scheduled out. However, readers under
> > enetc_poll cannot acquire the read lock again because a writer is already
> > waiting, leading to a thread hang.
> > 
> > Currently, the deadlock is avoided by adjusting enetc_lock_mdio to prevent
> > recursive lock acquisition.
> > 
> > Fixes: 6d36ecdbc441 ("net: enetc: take the MDIO lock only once per NAPI poll
> > cycle")
> > Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com>
> 
> Acked-by: Wei Fang <wei.fang@nxp.com>
> 
> Hi Vladimir,
> 
> Do you have any comments? This patch will cause the regression of performance
> degradation, but the RCU stalls are more severe.
>

I'm fine with the change in principle. It's my fault because I didn't
understand how rwlock writer starvation prevention is implemented, I
thought there would be no problem with reentrant readers.

But I wonder if xdp_do_flush() shouldn't also be outside the enetc_lock_mdio()
section. Flushing XDP buffs with XDP_REDIRECT action might lead to
enetc_xdp_xmit() being called, which also takes the lock...