On Wed, Feb 16, 2022 at 01:17:03PM +0900, Byungchul Park wrote:
[ 7.013330] =================================================== [ 7.013331] DEPT: Circular dependency has been detected. [ 7.013332] 5.17.0-rc1-00014-gcf3441bb2012 #2 Tainted: G W [ 7.013333] --------------------------------------------------- [ 7.013334] summary [ 7.013334] --------------------------------------------------- [ 7.013335] *** DEADLOCK *** [ 7.013335] [ 7.013335] context A [ 7.013336] [S] (unknown)(&(&ei->socket.wq.wait)->dmap:0) [ 7.013337] [W] __mutex_lock_common(&u->iolock:0) [ 7.013338] [E] event(&(&ei->socket.wq.wait)->dmap:0) [ 7.013340] [ 7.013340] context B [ 7.013341] [S] __raw_spin_lock(&u->lock:0) [ 7.013342] [W] wait(&(&ei->socket.wq.wait)->dmap:0) [ 7.013343] [E] spin_unlock(&u->lock:0)
This seems unlikely to be real. We're surely not actually waiting while holding a spinlock; existing debug checks would catch it.
[ 7.013407] --------------------------------------------------- [ 7.013407] context B's detail [ 7.013408] --------------------------------------------------- [ 7.013408] context B [ 7.013409] [S] __raw_spin_lock(&u->lock:0) [ 7.013410] [W] wait(&(&ei->socket.wq.wait)->dmap:0) [ 7.013411] [E] spin_unlock(&u->lock:0) [ 7.013412] [ 7.013412] [S] __raw_spin_lock(&u->lock:0): [ 7.013413] [<ffffffff81aa451f>] unix_stream_read_generic+0x6bf/0xb60 [ 7.013416] stacktrace: [ 7.013416] _raw_spin_lock+0x6e/0x90 [ 7.013418] unix_stream_read_generic+0x6bf/0xb60
It would be helpful if you'd run this through scripts/decode_stacktrace.sh so we could see line numbers instead of hex offsets (which arene't much use without the binary kernel).
[ 7.013420] unix_stream_recvmsg+0x40/0x50 [ 7.013422] sock_read_iter+0x85/0xd0 [ 7.013424] new_sync_read+0x162/0x180 [ 7.013426] vfs_read+0xf3/0x190 [ 7.013428] ksys_read+0xa6/0xc0 [ 7.013429] do_syscall_64+0x3a/0x90 [ 7.013431] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 7.013433] [ 7.013434] [W] wait(&(&ei->socket.wq.wait)->dmap:0): [ 7.013434] [<ffffffff810bb017>] prepare_to_wait+0x47/0xd0
... this may be the source of confusion. Just because we prepare to wait doesn't mean we end up actually waiting. For example, look at unix_wait_for_peer():
prepare_to_wait_exclusive(&u->peer_wait, &wait, TASK_INTERRUPTIBLE);
sched = !sock_flag(other, SOCK_DEAD) && !(other->sk_shutdown & RCV_SHUTDOWN) && unix_recvq_full(other);
unix_state_unlock(other);
if (sched) timeo = schedule_timeout(timeo);
finish_wait(&u->peer_wait, &wait);
We *prepare* to wait, *then* drop the lock, then actually schedule.