From: syzbot <syzbot+8040d16d30c215f821de@syzkaller.appspotmail.com>
To: bongsu.jeon@samsung.com, krzysztof.kozlowski@linaro.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: [syzbot] possible deadlock in virtual_nci_close
Date: Sun, 13 Nov 2022 19:11:51 -0800 [thread overview]
Message-ID: <000000000000cceef005ed659943@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: af7a05689189 Merge tag 'mips-fixes_6.1_1' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d30249880000
kernel config: https://syzkaller.appspot.com/x/.config?x=9d1d2dd6d424a076
dashboard link: https://syzkaller.appspot.com/bug?extid=8040d16d30c215f821de
compiler: aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm64
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8040d16d30c215f821de@syzkaller.appspotmail.com
nci: __nci_request: wait_for_completion_interruptible_timeout failed 0
======================================================
WARNING: possible circular locking dependency detected
6.1.0-rc4-syzkaller-00372-gaf7a05689189 #0 Not tainted
------------------------------------------------------
syz-executor.1/8551 is trying to acquire lock:
ffff80000e6854c8 (nci_mutex){+.+.}-{3:3}, at: virtual_nci_close+0x2c/0x60 drivers/nfc/virtual_ncidev.c:44
but task is already holding lock:
ffff000030115350 (&ndev->req_lock){+.+.}-{3:3}, at: nci_close_device+0x5c/0x360 net/nfc/nci/core.c:560
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&ndev->req_lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x124/0x83c kernel/locking/mutex.c:747
mutex_lock_nested+0x2c/0x40 kernel/locking/mutex.c:799
nci_request net/nfc/nci/core.c:148 [inline]
nci_set_local_general_bytes net/nfc/nci/core.c:774 [inline]
nci_start_poll+0x36c/0x624 net/nfc/nci/core.c:838
nfc_start_poll+0x114/0x270 net/nfc/core.c:225
nfc_genl_start_poll+0x154/0x3b0 net/nfc/netlink.c:828
genl_family_rcv_msg_doit+0x1b8/0x2a0 net/netlink/genetlink.c:756
genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
genl_rcv_msg+0x2f8/0x594 net/netlink/genetlink.c:850
netlink_rcv_skb+0x180/0x330 net/netlink/af_netlink.c:2540
genl_rcv+0x38/0x50 net/netlink/genetlink.c:861
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x3ec/0x684 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x690/0xb1c net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xc0/0xf4 net/socket.c:734
____sys_sendmsg+0x534/0x6b0 net/socket.c:2482
___sys_sendmsg+0xf0/0x174 net/socket.c:2536
__sys_sendmsg+0xc4/0x154 net/socket.c:2565
__do_sys_sendmsg net/socket.c:2574 [inline]
__se_sys_sendmsg net/socket.c:2572 [inline]
__arm64_sys_sendmsg+0x70/0xa0 net/socket.c:2572
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x6c/0x260 arch/arm64/kernel/syscall.c:52
el0_svc_common.constprop.0+0xc4/0x254 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x50/0x14c arch/arm64/kernel/syscall.c:206
el0_svc+0x54/0x140 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0xb8/0xc0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581
-> #2 (&genl_data->genl_data_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x124/0x83c kernel/locking/mutex.c:747
mutex_lock_nested+0x2c/0x40 kernel/locking/mutex.c:799
nfc_urelease_event_work+0x118/0x270 net/nfc/netlink.c:1811
process_one_work+0x780/0x184c kernel/workqueue.c:2289
worker_thread+0x3cc/0xc40 kernel/workqueue.c:2436
kthread+0x23c/0x2a0 kernel/kthread.c:376
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
-> #1 (nfc_devlist_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x124/0x83c kernel/locking/mutex.c:747
mutex_lock_nested+0x2c/0x40 kernel/locking/mutex.c:799
nfc_register_device+0x34/0x320 net/nfc/core.c:1116
nci_register_device+0x604/0x8c0 net/nfc/nci/core.c:1256
virtual_ncidev_open+0x64/0xe0 drivers/nfc/virtual_ncidev.c:146
misc_open+0x294/0x394 drivers/char/misc.c:143
chrdev_open+0x1c0/0x54c fs/char_dev.c:414
do_dentry_open+0x3c4/0xf40 fs/open.c:882
vfs_open+0x90/0xd0 fs/open.c:1013
do_open fs/namei.c:3557 [inline]
path_openat+0x1030/0x1fe0 fs/namei.c:3713
do_filp_open+0x154/0x330 fs/namei.c:3740
do_sys_openat2+0x124/0x390 fs/open.c:1310
do_sys_open fs/open.c:1326 [inline]
__do_sys_openat fs/open.c:1342 [inline]
__se_sys_openat fs/open.c:1337 [inline]
__arm64_sys_openat+0x130/0x1c0 fs/open.c:1337
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x6c/0x260 arch/arm64/kernel/syscall.c:52
el0_svc_common.constprop.0+0xc4/0x254 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x50/0x14c arch/arm64/kernel/syscall.c:206
el0_svc+0x54/0x140 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0xb8/0xc0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581
-> #0 (nci_mutex){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain kernel/locking/lockdep.c:3831 [inline]
__lock_acquire+0x2788/0x56d0 kernel/locking/lockdep.c:5055
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x58c/0x9a0 kernel/locking/lockdep.c:5633
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x124/0x83c kernel/locking/mutex.c:747
mutex_lock_nested+0x2c/0x40 kernel/locking/mutex.c:799
virtual_nci_close+0x2c/0x60 drivers/nfc/virtual_ncidev.c:44
nci_close_device+0x200/0x360 net/nfc/nci/core.c:592
nci_unregister_device+0x40/0x280 net/nfc/nci/core.c:1291
virtual_ncidev_close+0x70/0x90 drivers/nfc/virtual_ncidev.c:166
__fput+0x1ac/0x860 fs/file_table.c:320
____fput+0x10/0x1c fs/file_table.c:348
task_work_run+0x12c/0x220 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
do_notify_resume+0x920/0x2840 arch/arm64/kernel/signal.c:1127
prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline]
exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline]
el0_svc+0x11c/0x140 arch/arm64/kernel/entry-common.c:638
el0t_64_sync_handler+0xb8/0xc0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581
other info that might help us debug this:
Chain exists of:
nci_mutex --> &genl_data->genl_data_mutex --> &ndev->req_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ndev->req_lock);
lock(&genl_data->genl_data_mutex);
lock(&ndev->req_lock);
lock(nci_mutex);
*** DEADLOCK ***
1 lock held by syz-executor.1/8551:
#0: ffff000030115350 (&ndev->req_lock){+.+.}-{3:3}, at: nci_close_device+0x5c/0x360 net/nfc/nci/core.c:560
stack backtrace:
CPU: 1 PID: 8551 Comm: syz-executor.1 Not tainted 6.1.0-rc4-syzkaller-00372-gaf7a05689189 #0
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0xe0/0x140 arch/arm64/kernel/stacktrace.c:156
show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x9c/0xd8 lib/dump_stack.c:106
dump_stack+0x1c/0x38 lib/dump_stack.c:113
print_circular_bug+0x2d4/0x2ec kernel/locking/lockdep.c:2055
check_noncircular+0x26c/0x2e0 kernel/locking/lockdep.c:2177
check_prev_add kernel/locking/lockdep.c:3097 [inline]
check_prevs_add kernel/locking/lockdep.c:3216 [inline]
validate_chain kernel/locking/lockdep.c:3831 [inline]
__lock_acquire+0x2788/0x56d0 kernel/locking/lockdep.c:5055
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x58c/0x9a0 kernel/locking/lockdep.c:5633
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__mutex_lock+0x124/0x83c kernel/locking/mutex.c:747
mutex_lock_nested+0x2c/0x40 kernel/locking/mutex.c:799
virtual_nci_close+0x2c/0x60 drivers/nfc/virtual_ncidev.c:44
nci_close_device+0x200/0x360 net/nfc/nci/core.c:592
nci_unregister_device+0x40/0x280 net/nfc/nci/core.c:1291
virtual_ncidev_close+0x70/0x90 drivers/nfc/virtual_ncidev.c:166
__fput+0x1ac/0x860 fs/file_table.c:320
____fput+0x10/0x1c fs/file_table.c:348
task_work_run+0x12c/0x220 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
do_notify_resume+0x920/0x2840 arch/arm64/kernel/signal.c:1127
prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline]
exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline]
el0_svc+0x11c/0x140 arch/arm64/kernel/entry-common.c:638
el0t_64_sync_handler+0xb8/0xc0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581
---
This report 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 syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
next reply other threads:[~2022-11-14 3:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-14 3:11 syzbot [this message]
2022-11-14 9:48 ` [syzbot] possible deadlock in virtual_nci_close Dmitry Vyukov
2022-11-14 14:55 ` syzbot
2022-11-16 5:58 ` syzbot
2022-11-22 13:08 ` Dmitry Vyukov
[not found] <20221115102048.2433-1-hdanton@sina.com>
2022-11-15 10:50 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=000000000000cceef005ed659943@google.com \
--to=syzbot+8040d16d30c215f821de@syzkaller.appspotmail.com \
--cc=bongsu.jeon@samsung.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.