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->lockIncluding 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