possible deadlock in do_tcp_setsockopt

5 views
Skip to first unread message

syzbot

unread,
Mar 7, 2020, 5:03:12 PM3/7/20
to syzkaller...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: 78d697fc Linux 4.14.172
git tree: linux-4.14.y
console output: https://syzkaller.appspot.com/x/log.txt?x=12052ae3e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=3484a1ea90b8523a
dashboard link: https://syzkaller.appspot.com/bug?extid=b22de9395f7370b50aef
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b22de9...@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
4.14.172-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:7/20264 is trying to acquire lock:
(k-sk_lock-AF_INET){+.+.}, at: [<ffffffff854b470b>] lock_sock include/net/sock.h:1467 [inline]
(k-sk_lock-AF_INET){+.+.}, at: [<ffffffff854b470b>] do_tcp_setsockopt.isra.0+0xfb/0x1c70 net/ipv4/tcp.c:2557

but task is already holding lock:
((&(&cp->cp_send_w)->work)){+.+.}, at: [<ffffffff813b5861>] process_one_work+0x761/0x1540 kernel/workqueue.c:2089

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 ((&(&cp->cp_send_w)->work)){+.+.}:
flush_work+0xae/0x780 kernel/workqueue.c:2887
__cancel_work_timer+0x2d0/0x460 kernel/workqueue.c:2962
rds_tcp_reset_callbacks+0x18d/0x450 net/rds/tcp.c:167
rds_tcp_accept_one+0x618/0x8b0 net/rds/tcp_listen.c:194
rds_tcp_accept_worker+0x4d/0x70 net/rds/tcp.c:407
process_one_work+0x813/0x1540 kernel/workqueue.c:2114
worker_thread+0x5d1/0x1070 kernel/workqueue.c:2248
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404

-> #0 (k-sk_lock-AF_INET){+.+.}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3994
lock_sock_nested+0xb7/0x100 net/core/sock.c:2770
lock_sock include/net/sock.h:1467 [inline]
do_tcp_setsockopt.isra.0+0xfb/0x1c70 net/ipv4/tcp.c:2557
tcp_setsockopt+0xa7/0xc0 net/ipv4/tcp.c:2828
kernel_setsockopt+0xfb/0x1b0 net/socket.c:3396
rds_tcp_cork net/rds/tcp_send.c:43 [inline]
rds_tcp_xmit_path_prepare+0xaf/0xe0 net/rds/tcp_send.c:50
rds_send_xmit+0x1cc/0x1c20 net/rds/send.c:187
rds_send_worker+0x6d/0x240 net/rds/threads.c:189
process_one_work+0x813/0x1540 kernel/workqueue.c:2114
worker_thread+0x5d1/0x1070 kernel/workqueue.c:2248
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock((&(&cp->cp_send_w)->work));
lock(k-sk_lock-AF_INET);
lock((&(&cp->cp_send_w)->work));
lock(k-sk_lock-AF_INET);

*** DEADLOCK ***

2 locks held by kworker/u4:7/20264:
#0: ("%s""krdsd"){+.+.}, at: [<ffffffff813b5827>] work_static include/linux/workqueue.h:199 [inline]
#0: ("%s""krdsd"){+.+.}, at: [<ffffffff813b5827>] set_work_data kernel/workqueue.c:619 [inline]
#0: ("%s""krdsd"){+.+.}, at: [<ffffffff813b5827>] set_work_pool_and_clear_pending kernel/workqueue.c:646 [inline]
#0: ("%s""krdsd"){+.+.}, at: [<ffffffff813b5827>] process_one_work+0x727/0x1540 kernel/workqueue.c:2085
#1: ((&(&cp->cp_send_w)->work)){+.+.}, at: [<ffffffff813b5861>] process_one_work+0x761/0x1540 kernel/workqueue.c:2089

stack backtrace:
CPU: 0 PID: 20264 Comm: kworker/u4:7 Not tainted 4.14.172-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: krdsd rds_send_worker
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x13e/0x194 lib/dump_stack.c:58
print_circular_bug.isra.0.cold+0x1c4/0x282 kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1901 [inline]
check_prevs_add kernel/locking/lockdep.c:2018 [inline]
validate_chain kernel/locking/lockdep.c:2460 [inline]
__lock_acquire+0x2cb3/0x4620 kernel/locking/lockdep.c:3487
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3994
lock_sock_nested+0xb7/0x100 net/core/sock.c:2770
lock_sock include/net/sock.h:1467 [inline]
do_tcp_setsockopt.isra.0+0xfb/0x1c70 net/ipv4/tcp.c:2557
tcp_setsockopt+0xa7/0xc0 net/ipv4/tcp.c:2828
kernel_setsockopt+0xfb/0x1b0 net/socket.c:3396
rds_tcp_cork net/rds/tcp_send.c:43 [inline]
rds_tcp_xmit_path_prepare+0xaf/0xe0 net/rds/tcp_send.c:50
rds_send_xmit+0x1cc/0x1c20 net/rds/send.c:187
rds_send_worker+0x6d/0x240 net/rds/threads.c:189
process_one_work+0x813/0x1540 kernel/workqueue.c:2114
worker_thread+0x5d1/0x1070 kernel/workqueue.c:2248
kthread+0x30d/0x420 kernel/kthread.c:232
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:404


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

syzbot

unread,
Oct 8, 2021, 6:18:16 AM10/8/21
to syzkaller...@googlegroups.com
Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.
Reply all
Reply to author
Forward
0 new messages