possible deadlock in strp_work

[syzbot]

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=10697f29e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=3484a1ea90b8523a
dashboard link: https://syzkaller.appspot.com/bug?extid=2d18205a9696fdf247d6
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+2d1820...@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected
4.14.172-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:2/28 is trying to acquire lock:
(sk_lock-AF_INET){+.+.}, at: [<ffffffff85be8d8e>] do_strp_work net/strparser/strparser.c:415 [inline]
(sk_lock-AF_INET){+.+.}, at: [<ffffffff85be8d8e>] strp_work+0x3e/0x100 net/strparser/strparser.c:434

but task is already holding lock:
((&strp->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 ((&strp->work)){+.+.}:
flush_work+0xae/0x780 kernel/workqueue.c:2887
__cancel_work_timer+0x2d0/0x460 kernel/workqueue.c:2962
strp_done+0x53/0xd0 net/strparser/strparser.c:519
kcm_attach net/kcm/kcmsock.c:1429 [inline]
kcm_attach_ioctl net/kcm/kcmsock.c:1490 [inline]
kcm_ioctl+0x856/0x1010 net/kcm/kcmsock.c:1701
sock_do_ioctl+0x5f/0xa0 net/socket.c:974
sock_ioctl+0x28d/0x450 net/socket.c:1071
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x75a/0xfe0 fs/ioctl.c:684
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x7f/0xb0 fs/ioctl.c:692
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292
entry_SYSCALL_64_after_hwframe+0x42/0xb7

-> #0 (sk_lock-AF_INET){+.+.}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3994
lock_sock_nested+0xb7/0x100 net/core/sock.c:2770
do_strp_work net/strparser/strparser.c:415 [inline]
strp_work+0x3e/0x100 net/strparser/strparser.c:434
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((&strp->work));
lock(sk_lock-AF_INET);
lock((&strp->work));
lock(sk_lock-AF_INET);

*** DEADLOCK ***

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

stack backtrace:
CPU: 1 PID: 28 Comm: kworker/u4:2 Not tainted 4.14.172-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: kstrp strp_work
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
do_strp_work net/strparser/strparser.c:415 [inline]
strp_work+0x3e/0x100 net/strparser/strparser.c:434
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
nla_parse: 730 callbacks suppressed
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
nla_parse: 842 callbacks suppressed
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.2'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.2'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.4'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.1'.
netlink: 44 bytes leftover after parsing attributes in process `syz-executor.2'.


---
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]

syzbot has found a reproducer for the following issue on:

HEAD commit: 8961076e Linux 4.14.207
git tree: linux-4.14.y
console output: https://syzkaller.appspot.com/x/log.txt?x=158f08f2500000
kernel config: https://syzkaller.appspot.com/x/.config?x=44f5233cc1f5c95d
dashboard link: https://syzkaller.appspot.com/bug?extid=2d18205a9696fdf247d6
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=120e581c500000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17e33981500000

IMPORTANT: if you fix the issue, please add the following tag to the commit:

Reported-by: syzbot+2d1820...@syzkaller.appspotmail.com

======================================================
WARNING: possible circular locking dependency detected

4.14.207-syzkaller #0 Not tainted
------------------------------------------------------
kworker/u4:3/340 is trying to acquire lock:
(sk_lock-AF_INET){+.+.}, at: [<ffffffff869dac6e>] do_strp_work net/strparser/strparser.c:415 [inline]
(sk_lock-AF_INET){+.+.}, at: [<ffffffff869dac6e>] strp_work+0x3e/0x100 net/strparser/strparser.c:434

but task is already holding lock:

((&strp->work)){+.+.}, at: [<ffffffff81373646>] process_one_work+0x6e6/0x14a0 kernel/workqueue.c:2091

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 ((&strp->work)){+.+.}:

flush_work+0xad/0x770 kernel/workqueue.c:2889
__cancel_work_timer+0x321/0x460 kernel/workqueue.c:2964

strp_done+0x53/0xd0 net/strparser/strparser.c:519
kcm_attach net/kcm/kcmsock.c:1429 [inline]
kcm_attach_ioctl net/kcm/kcmsock.c:1490 [inline]

kcm_ioctl+0x828/0xfb0 net/kcm/kcmsock.c:1701
sock_do_ioctl net/socket.c:974 [inline]
sock_ioctl+0x2cc/0x4c0 net/socket.c:1071

vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]

do_vfs_ioctl+0x75a/0xff0 fs/ioctl.c:684

SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x7f/0xb0 fs/ioctl.c:692
do_syscall_64+0x1d5/0x640 arch/x86/entry/common.c:292

entry_SYSCALL_64_after_hwframe+0x46/0xbb

-> #0 (sk_lock-AF_INET){+.+.}:
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
lock_sock_nested+0xb7/0x100 net/core/sock.c:2796

do_strp_work net/strparser/strparser.c:415 [inline]
strp_work+0x3e/0x100 net/strparser/strparser.c:434

process_one_work+0x793/0x14a0 kernel/workqueue.c:2116
worker_thread+0x5cc/0xff0 kernel/workqueue.c:2250

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((&strp->work));
lock(sk_lock-AF_INET);
lock((&strp->work));
lock(sk_lock-AF_INET);

*** DEADLOCK ***

2 locks held by kworker/u4:3/340:
#0: ("%s""kstrp"){+.+.}, at: [<ffffffff81373610>] process_one_work+0x6b0/0x14a0 kernel/workqueue.c:2087
#1: ((&strp->work)){+.+.}, at: [<ffffffff81373646>] process_one_work+0x6e6/0x14a0 kernel/workqueue.c:2091

stack backtrace:
CPU: 1 PID: 340 Comm: kworker/u4:3 Not tainted 4.14.207-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: kstrp strp_work
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]

dump_stack+0x1b2/0x283 lib/dump_stack.c:58
print_circular_bug.constprop.0.cold+0x2d7/0x41e kernel/locking/lockdep.c:1258
check_prev_add kernel/locking/lockdep.c:1905 [inline]
check_prevs_add kernel/locking/lockdep.c:2022 [inline]
validate_chain kernel/locking/lockdep.c:2464 [inline]
__lock_acquire+0x2e0e/0x3f20 kernel/locking/lockdep.c:3491
lock_acquire+0x170/0x3f0 kernel/locking/lockdep.c:3998
lock_sock_nested+0xb7/0x100 net/core/sock.c:2796

do_strp_work net/strparser/strparser.c:415 [inline]
strp_work+0x3e/0x100 net/strparser/strparser.c:434

process_one_work+0x793/0x14a0 kernel/workqueue.c:2116