[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20241129-glimpse-wilt-8a9ba002d7bf@spud>
Date: Fri, 29 Nov 2024 12:23:28 +0000
From: Conor Dooley <conor@...nel.org>
To: netdev@...r.kernel.org
Cc: Nicolas Ferre <nicolas.ferre@...rochip.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Andrew Lunn <andrew+netdev@...n.ch>, davem@...emloft.net,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
linux-kernel@...r.kernel.org, conor@...nel.org
Subject: deadlock in macb_start_xmit() with PREEMPT_RT enabled
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
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists