[PATCH v2] net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()
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... 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);
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->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
linux-stable-mirror@lists.linaro.org
-
Paolo Abeni -
Xiaolei Wang -
xiaolei wang