vector: spinlock ordering problems
Johannes Berg
johannes at sipsolutions.net
Wed Jul 3 09:26:14 PDT 2024
Lockdep reports a spinlock ordering problem: sometimes we take head_lock
first, sometimes tail_lock, so there's a classic ABBA deadlock possible.
It may not happen now because of UML being single-CPU and all that, but
perhaps with preempt?
Report:
======================================================
WARNING: possible circular locking dependency detected
6.10.0-rc6-00036-gcd01672d64a3 #26 Not tainted
------------------------------------------------------
systemd-network/105 is trying to acquire lock:
00000000622bd8b0 (&result->tail_lock){+...}-{2:2}, at: vector_send+0x1c5/0x266
but task is already holding lock:
00000000622bd870 (&result->head_lock){+...}-{2:2}, at: vector_send+0x3b/0x266
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&result->head_lock){+...}-{2:2}:
save_stack_trace+0x32/0x34
stack_trace_save+0x38/0x3d
save_trace+0x90/0x268
__lock_acquire+0x146c/0x15a4
lock_acquire+0x2e1/0x38d
_raw_spin_lock+0x43/0x5a
vector_net_start_xmit+0x1ef/0x3bd
netdev_start_xmit+0x51/0x80
dev_hard_start_xmit+0x137/0x22f
sch_direct_xmit+0xc6/0x2a3
__dev_queue_xmit+0x3da/0x877
packet_xmit+0x3c/0xf2
packet_sendmsg+0x106a/0x10d0
sock_sendmsg_nosec+0x1c/0x98
__sys_sendto+0x113/0x147
sys_sendto+0x14/0x18
handle_syscall+0xa8/0xd8
userspace+0x323/0x4e5
fork_handler+0x8c/0x8e
-> #0 (&result->tail_lock){+...}-{2:2}:
save_stack_trace+0x32/0x34
stack_trace_save+0x38/0x3d
save_trace+0x90/0x268
print_circular_bug+0x68/0x2b5
check_noncircular+0x11c/0x12c
__lock_acquire+0x12a4/0x15a4
lock_acquire+0x2e1/0x38d
_raw_spin_lock+0x43/0x5a
vector_send+0x1c5/0x266
vector_net_start_xmit+0x394/0x3bd
netdev_start_xmit+0x51/0x80
dev_hard_start_xmit+0x137/0x22f
sch_direct_xmit+0xc6/0x2a3
__dev_queue_xmit+0x3da/0x877
packet_xmit+0x3c/0xf2
packet_sendmsg+0x106a/0x10d0
sock_sendmsg_nosec+0x1c/0x98
__sys_sendto+0x113/0x147
sys_sendto+0x14/0x18
handle_syscall+0xa8/0xd8
userspace+0x323/0x4e5
fork_handler+0x8c/0x8e
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&result->head_lock);
lock(&result->tail_lock);
lock(&result->head_lock);
lock(&result->tail_lock);
*** DEADLOCK ***
4 locks held by systemd-network/105:
#0: 0000000060749920 (rcu_read_lock_bh){....}-{1:2}, at: rcu_lock_acquire+0x16/0x30
#1: 0000000066a47210 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin+0x2e/0x66
#2: 000000006227f690 (_xmit_ETHER#2){+...}-{2:2}, at: sch_direct_xmit+0x9b/0x2a3
#3: 00000000622bd870 (&result->head_lock){+...}-{2:2}, at: vector_send+0x3b/0x266
stack backtrace:
CPU: 0 PID: 105 Comm: systemd-network Not tainted 6.10.0-rc6-00036-gcd01672d64a3 #26
Stack:
812c7710 604c0e3b 000000ea 00000000
ffffff00 6064f6f1 604de3a0 6063beda
812c7740 604e8b7c 000000ec 604df56f
Call Trace:
[<604df56f>] ? _printk+0x0/0x98
[<6002b386>] show_stack+0x141/0x150
[<604c0e3b>] ? dump_stack_print_info+0xe2/0xf1
[<604de3a0>] ? __print_lock_name+0x0/0xbd
[<604e8b7c>] dump_stack_lvl+0x71/0xb8
[<604df56f>] ? _printk+0x0/0x98
[<604e8be1>] dump_stack+0x1e/0x20
[<6009348a>] print_circular_bug+0x2a6/0x2b5
[<600c8e7d>] ? stack_trace_save+0x38/0x3d
[<60090fbf>] ? save_trace+0x90/0x268
[<600935b5>] check_noncircular+0x11c/0x12c
[<600acb42>] ? rcu_read_lock_any_held+0x40/0x9c
[<604ea4ec>] ? __this_cpu_preempt_check+0x14/0x16
[<60091cc6>] ? lookup_chain_cache+0x4e/0x130
[<60090d22>] ? hlock_class+0x0/0xa3
[<600963be>] __lock_acquire+0x12a4/0x15a4
[<604ea4d8>] ? __this_cpu_preempt_check+0x0/0x16
[<60095034>] lock_acquire+0x2e1/0x38d
[<60034e49>] ? vector_send+0x1c5/0x266
[<604e9cf7>] ? debug_lockdep_rcu_enabled+0x0/0x3f
[<604e9cf7>] ? debug_lockdep_rcu_enabled+0x0/0x3f
[<604f2532>] _raw_spin_lock+0x43/0x5a
[<60034e49>] ? vector_send+0x1c5/0x266
[<604f24ef>] ? _raw_spin_lock+0x0/0x5a
[<60034e49>] vector_send+0x1c5/0x266
[<604f28bb>] ? _raw_spin_unlock+0x0/0x7c
[<6003538c>] vector_net_start_xmit+0x394/0x3bd
[<604ea4d8>] ? __this_cpu_preempt_check+0x0/0x16
[<603d0711>] netdev_start_xmit+0x51/0x80
[<600b09cd>] ? rcu_is_watching+0x0/0x6f
[<603d79f9>] dev_hard_start_xmit+0x137/0x22f
[<6041a35b>] sch_direct_xmit+0xc6/0x2a3
[<603d15a7>] ? qdisc_run_end+0x0/0x52
[<603d7f6b>] __dev_queue_xmit+0x3da/0x877
[<603b3f55>] ? skb_set_owner_w+0x96/0x9b
[<604ba1b5>] packet_xmit+0x3c/0xf2
[<604bfbc2>] packet_sendmsg+0x106a/0x10d0
[<6002e30a>] ? copy_chunk_from_user+0x26/0x30
[<6002e2e4>] ? copy_chunk_from_user+0x0/0x30
[<6002e592>] ? do_op_one_page+0x9d/0xa9
[<60150008>] ? __gup_longterm_locked+0x39b/0x618
[<603af0f0>] sock_sendmsg_nosec+0x1c/0x98
[<603b13ca>] __sys_sendto+0x113/0x147
[<600f8264>] ? __seccomp_filter+0xa9/0x3c7
[<6004682f>] ? switch_threads+0x28/0x57
[<603b1412>] sys_sendto+0x14/0x18
[<6002e252>] handle_syscall+0xa8/0xd8
[<60046631>] userspace+0x323/0x4e5
[<6002a494>] ? interrupt_end+0x0/0xe4
[<6002a3c3>] fork_handler+0x8c/0x8e
More information about the linux-um
mailing list