In the non-RT kernel, local_bh_disable() merely disables preemption,
whereas it maps to an actual spin lock in the RT kernel. Consequently,
when attempting to refill RX buffers via netdev_alloc_skb() in
macb_mac_link_up(), a deadlock scenario arises as follows:
  Chain caused by macb_mac_link_up():
   &bp->lock --> (softirq_ctrl.lock)

   Chain caused by macb_start_xmit():
   (softirq_ctrl.lock) --> _xmit_ETHER#2 --> &bp->lock

Notably, invoking the mog_init_rings() callback upon link establishment
is unnecessary. Instead, we can exclusively call mog_init_rings() within
the ndo_open() callback. This adjustment resolves the deadlock issue.
Given that mog_init_rings() is only applicable to
non-MACB_CAPS_MACB_IS_EMAC cases, we can simply move it to macb_open()
and simultaneously eliminate the MACB_CAPS_MACB_IS_EMAC check.

Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()")
Cc: stable@vger.kernel.org
Suggested-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---

V1: https://patchwork.kernel.org/project/netdevbpf/patch/20251128103647.351259-1-xiaolei.wang@windriver.com/
V2: Update the correct lock dependency chain and add the Fix tag.

 drivers/net/ethernet/cadence/macb_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index ca2386b83473..064fccdcf699 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -744,7 +744,6 @@ static void macb_mac_link_up(struct phylink_config *config,
 		/* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
 		 * cleared the pipeline and control registers.
 		 */
-		bp->macbgem_ops.mog_init_rings(bp);
 		macb_init_buffers(bp);
 
 		for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue)
@@ -2991,6 +2990,8 @@ static int macb_open(struct net_device *dev)
 		goto pm_exit;
 	}
 
+	bp->macbgem_ops.mog_init_rings(bp);
+
 	for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
 		napi_enable(&queue->napi_rx);
 		napi_enable(&queue->napi_tx);
-- 
2.43.0

On 12/9/25 9:52 AM, Xiaolei Wang wrote:
> In the non-RT kernel, local_bh_disable() merely disables preemption,
> whereas it maps to an actual spin lock in the RT kernel. Consequently,
> when attempting to refill RX buffers via netdev_alloc_skb() in
> macb_mac_link_up(), a deadlock scenario arises as follows:
>   Chain caused by macb_mac_link_up():
>    &bp->lock --> (softirq_ctrl.lock)
> 
>    Chain caused by macb_start_xmit():
>    (softirq_ctrl.lock) --> _xmit_ETHER#2 --> &bp->lock

Including the whole lockdep splat instead of the above would be clearer;
in fact, I had to fetch the relevant info from there.

> Notably, invoking the mog_init_rings() callback upon link establishment
> is unnecessary. Instead, we can exclusively call mog_init_rings() within
> the ndo_open() callback. This adjustment resolves the deadlock issue.
> Given that mog_init_rings() is only applicable to
> non-MACB_CAPS_MACB_IS_EMAC cases, we can simply move it to macb_open()
> and simultaneously eliminate the MACB_CAPS_MACB_IS_EMAC check.

This part is not clear to me: AFAICS the new code now does such init
step unconditionally, which looks confusing. I think such step should
still be under the relevant conditional (or you need to include a
better/more verbose explanation describing why such check is not really
needed).

> Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()")
> Cc: stable@vger.kernel.org
> Suggested-by: Kevin Hao <kexin.hao@windriver.com>
> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>

Side note: you still need to include the 'net' tag into the subj prefix.

/P

On 12/18/25 20:14, Paolo Abeni wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On 12/9/25 9:52 AM, Xiaolei Wang wrote:
>> In the non-RT kernel, local_bh_disable() merely disables preemption,
>> whereas it maps to an actual spin lock in the RT kernel. Consequently,
>> when attempting to refill RX buffers via netdev_alloc_skb() in
>> macb_mac_link_up(), a deadlock scenario arises as follows:
>>    Chain caused by macb_mac_link_up():
>>     &bp->lock --> (softirq_ctrl.lock)
>>
>>     Chain caused by macb_start_xmit():
>>     (softirq_ctrl.lock) --> _xmit_ETHER#2 --> &bp->lock
> Including the whole lockdep splat instead of the above would be clearer;
> in fact, I had to fetch the relevant info from there.
OK, I will add all the logs.
>
>> Notably, invoking the mog_init_rings() callback upon link establishment
>> is unnecessary. Instead, we can exclusively call mog_init_rings() within
>> the ndo_open() callback. This adjustment resolves the deadlock issue.
>> Given that mog_init_rings() is only applicable to
>> non-MACB_CAPS_MACB_IS_EMAC cases, we can simply move it to macb_open()
>> and simultaneously eliminate the MACB_CAPS_MACB_IS_EMAC check.
> This part is not clear to me: AFAICS the new code now does such init
> step unconditionally, which looks confusing. I think such step should
> still be under the relevant conditional (or you need to include a
> better/more verbose explanation describing why such check is not really
> needed).

I noticed that the initialization function in 'emac_config' is 
'at91ether_init()',

and 'netdev_ops' is 'at91ether_netdev_ops'. It doesn't use 'macb_open()',

so after moving 'mog_init_rings()' to 'macb_open', we no longer need to 
add this check.

>
>> Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()")
>> Cc: stable@vger.kernel.org
>> Suggested-by: Kevin Hao <kexin.hao@windriver.com>
>> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> Side note: you still need to include the 'net' tag into the subj prefix.

OK, I will add "net" to the subject in the next version.

thanks

xiaolei

>
> /P
>