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

[Wei Fang]

> 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@xxxxxxxxxxxxx>

Acked-by: Wei Fang <wei.fang@xxxxxxx>

Hi Vladimir,

Do you have any comments? This patch will cause the regression of performance
degradation, but the RCU stalls are more severe.