Yo,

Just reporting a deadlock that I've been seeing since PREEMPT_RT was
merged in the cadence macb driver. I meant to report this weeks ago
after mentioning it to Nicolas but it slipped my mind. With PREEMPT_RT
disabled, the deadlock does not get reported.

Cheers,
Conor.

======================================================
WARNING: possible circular locking dependency detected
6.12.0-10553-gb86545e02e8c-dirty #1 Not tainted
------------------------------------------------------
kworker/0:1/9 is trying to acquire lock:
ffffffe5c0abb460 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x836/0xa3e

but task is already holding lock:
ffffffe5c0ab9270 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit+0x300/0xa3e

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 (&queue->tx_ptr_lock){+...}-{3:3}:
       __lock_acquire+0xadc/0xda6
       lock_acquire+0x124/0x2d0
       rt_spin_lock+0x3a/0x142
       macb_start_xmit+0x300/0xa3e
       dev_hard_start_xmit+0xf4/0x28c
       sch_direct_xmit+0xbc/0x324
       __dev_queue_xmit+0x5f6/0xb5e
       neigh_resolve_output+0x122/0x15a
       ip6_finish_output2+0x624/0xa06
       ip6_output+0x182/0x35a
       mld_sendpack+0x274/0x47e
       mld_ifc_work+0x254/0x400
       process_one_work+0x224/0x55a
       worker_thread+0x236/0x360
       kthread+0xf2/0x10c
       ret_from_fork+0xe/0x18

-> #2 (_xmit_ETHER#2){+...}-{3:3}:
       __lock_acquire+0xadc/0xda6
       lock_acquire+0x124/0x2d0
       rt_spin_lock+0x3a/0x142
       sch_direct_xmit+0x80/0x324
       __dev_queue_xmit+0x5f6/0xb5e
       neigh_resolve_output+0x122/0x15a
       ip6_finish_output2+0x624/0xa06
       ip6_output+0x182/0x35a
       mld_sendpack+0x274/0x47e
       mld_ifc_work+0x254/0x400
       process_one_work+0x224/0x55a
       worker_thread+0x236/0x360
       kthread+0xf2/0x10c
       ret_from_fork+0xe/0x18

-> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}:
       __lock_acquire+0xadc/0xda6
       lock_acquire+0x124/0x2d0
       rt_spin_lock+0x3a/0x142
       __local_bh_disable_ip+0x10c/0x1ec
       local_bh_disable+0x1c/0x24
       __netdev_alloc_skb+0x12e/0x232
       gem_rx_refill+0xf6/0x1ae
       gem_init_rings+0x56/0x110
       macb_mac_link_up+0xc0/0x2d6
       phylink_resolve+0x5f2/0x72e
       process_one_work+0x224/0x55a
       worker_thread+0x236/0x360
       kthread+0xf2/0x10c
       ret_from_fork+0xe/0x18

-> #0 (&bp->lock){+.+.}-{3:3}:
       check_noncircular+0x146/0x15c
       validate_chain+0xb86/0x2806
       __lock_acquire+0xadc/0xda6
       lock_acquire+0x124/0x2d0
       rt_spin_lock+0x3a/0x142
       macb_start_xmit+0x836/0xa3e
       dev_hard_start_xmit+0xf4/0x28c
       sch_direct_xmit+0xbc/0x324
       __dev_queue_xmit+0x5f6/0xb5e
       neigh_resolve_output+0x122/0x15a
       ip6_finish_output2+0x624/0xa06
       ip6_output+0x182/0x35a
       mld_sendpack+0x274/0x47e
       mld_ifc_work+0x254/0x400
       process_one_work+0x224/0x55a
       worker_thread+0x236/0x360
       kthread+0xf2/0x10c
       ret_from_fork+0xe/0x18

other info that might help us debug this:

Chain exists of:
  &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&queue->tx_ptr_lock);
                               lock(_xmit_ETHER#2);
                               lock(&queue->tx_ptr_lock);
  lock(&bp->lock);

 *** DEADLOCK ***

15 locks held by kworker/0:1/9:
 #0: ffffffe5c084f538 ((wq_completion)mld){+.+.}-{0:0}, at: process_one_work+0x194/0x55a
 #1: ffffffc600063d88 ((work_completion)(&(&idev->mc_ifc_work)->work)){+.+.}-{0:0}, at: process_one_work+0x1b2/0x55a
 #2: ffffffe5c5228620 (&idev->mc_lock){+.+.}-{4:4}, at: mld_ifc_work+0x2e/0x400
 #3: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x32
 #4: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x32
 #5: ffffffe5fef5c210 ((softirq_ctrl.lock)){+.+.}-{3:3}, at: __local_bh_disable_ip+0x10c/0x1ec
 #6: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x34
 #7: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x2e
 #8: ffffffff81ca92c8 (rcu_read_lock_bh){....}-{1:3}, at: rcu_lock_acquire+0x0/0x2a
 #9: ffffffe5c4ce7398 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{3:3}, at: __dev_queue_xmit+0x458/0xb5e
 #10: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x34
 #11: ffffffe5c5721318 (_xmit_ETHER#2){+...}-{3:3}, at: sch_direct_xmit+0x80/0x324
 #12: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x34
 #13: ffffffe5c0ab9270 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit+0x300/0xa3e
 #14: ffffffff81ca92a0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x0/0x34

stack backtrace:
CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.12.0-10553-gb86545e02e8c-dirty #1
Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
Workqueue: mld mld_ifc_work
Call Trace:
[<ffffffff80007870>] show_stack+0x2c/0x3c
[<ffffffff80c205dc>] dump_stack_lvl+0x32/0x9a
[<ffffffff80c20658>] dump_stack+0x14/0x1c
[<ffffffff8009a950>] print_circular_bug+0x320/0x326
[<ffffffff8009a3f0>] check_noncircular+0x146/0x15c
[<ffffffff80097eb2>] validate_chain+0xb86/0x2806
[<ffffffff80092c0e>] __lock_acquire+0xadc/0xda6
[<ffffffff80091eb2>] lock_acquire+0x124/0x2d0
[<ffffffff80c2bee2>] rt_spin_lock+0x3a/0x142
[<ffffffff80870788>] macb_start_xmit+0x836/0xa3e
[<ffffffff80a0a410>] dev_hard_start_xmit+0xf4/0x28c
[<ffffffff80a6ed88>] sch_direct_xmit+0xbc/0x324
[<ffffffff80a0b57c>] __dev_queue_xmit+0x5f6/0xb5e
[<ffffffff80a1feec>] neigh_resolve_output+0x122/0x15a
[<ffffffff80b2fcc0>] ip6_finish_output2+0x624/0xa06
[<ffffffff80b2ac3a>] ip6_output+0x182/0x35a
[<ffffffff80b67128>] mld_sendpack+0x274/0x47e
[<ffffffff80b642dc>] mld_ifc_work+0x254/0x400
[<ffffffff800451e6>] process_one_work+0x224/0x55a
[<ffffffff8004754e>] worker_thread+0x236/0x360
[<ffffffff8004e076>] kthread+0xf2/0x10c
[<ffffffff80c324e2>] ret_from_fork+0xe/0x18