From: syzbot <syzbot+e390d66dda462b51fde1@syzkaller.appspotmail.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com, willy@infradead.org
Subject: Re: [syzbot] [hfs?] possible deadlock in hfs_find_init (2)
Date: Sat, 21 Jan 2023 21:22:40 -0800 [thread overview]
Message-ID: <000000000000b31ed905f2d37856@google.com> (raw)
In-Reply-To: <000000000000a806c405f0c4c45b@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: edb2f0dc90f2 Merge branch 'for-next/core' into for-kernelci
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
console output: https://syzkaller.appspot.com/x/log.txt?x=12506805480000
kernel config: https://syzkaller.appspot.com/x/.config?x=a1c301efa2b11613
dashboard link: https://syzkaller.appspot.com/bug?extid=e390d66dda462b51fde1
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: arm64
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13d841fe480000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=134aa8fa480000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ca1677dc6969/disk-edb2f0dc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/22527595a2dd/vmlinux-edb2f0dc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/45308e5f6962/Image-edb2f0dc.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/7b6fdf809f4c/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e390d66dda462b51fde1@syzkaller.appspotmail.com
============================================
WARNING: possible recursive locking detected
6.2.0-rc4-syzkaller-16807-gedb2f0dc90f2 #0 Not tainted
--------------------------------------------
kworker/u4:3/103 is trying to acquire lock:
ffff0000c7f8c0b0 (&tree->tree_lock/1){+.+.}-{3:3}, at: hfs_find_init+0xac/0xcc
but task is already holding lock:
ffff0000c7f8c0b0 (&tree->tree_lock/1){+.+.}-{3:3}, at: hfs_find_init+0xac/0xcc
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&tree->tree_lock/1);
lock(&tree->tree_lock/1);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u4:3/103:
#0: ffff0000c0250138 ((wq_completion)writeback){+.+.}-{0:0}, at: process_one_work+0x270/0x504 kernel/workqueue.c:2262
#1: ffff80000f90bd80 ((work_completion)(&(&wb->dwork)->work)){+.+.}-{0:0}, at: process_one_work+0x29c/0x504 kernel/workqueue.c:2264
#2: ffff0000c7f8c0b0 (&tree->tree_lock/1){+.+.}-{3:3}, at: hfs_find_init+0xac/0xcc
#3: ffff0000cc2500f8 (&HFS_I(tree->inode)->extents_lock){+.+.}-{3:3}, at: hfs_extend_file+0x54/0x740 fs/hfs/extent.c:397
stack backtrace:
CPU: 1 PID: 103 Comm: kworker/u4:3 Not tainted 6.2.0-rc4-syzkaller-16807-gedb2f0dc90f2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: writeback wb_workfn (flush-7:0)
Call trace:
dump_backtrace+0x1c4/0x1f0 arch/arm64/kernel/stacktrace.c:156
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:163
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x104/0x16c lib/dump_stack.c:106
dump_stack+0x1c/0x58 lib/dump_stack.c:113
__lock_acquire+0x808/0x3084
lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5668
__mutex_lock_common+0xd4/0xca8 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x38/0x44 kernel/locking/mutex.c:799
hfs_find_init+0xac/0xcc
hfs_ext_read_extent fs/hfs/extent.c:200 [inline]
hfs_extend_file+0x120/0x740 fs/hfs/extent.c:401
hfs_bmap_reserve+0x44/0xe8 fs/hfs/btree.c:234
__hfs_ext_write_extent+0xb8/0x138 fs/hfs/extent.c:121
hfs_ext_write_extent+0x9c/0xd8 fs/hfs/extent.c:144
hfs_write_inode+0x68/0x478 fs/hfs/inode.c:431
write_inode fs/fs-writeback.c:1451 [inline]
__writeback_single_inode+0x240/0x2e4 fs/fs-writeback.c:1663
writeback_sb_inodes+0x308/0x678 fs/fs-writeback.c:1889
wb_writeback+0x198/0x328 fs/fs-writeback.c:2063
wb_do_writeback+0xc8/0x384 fs/fs-writeback.c:2206
wb_workfn+0x70/0x15c fs/fs-writeback.c:2246
process_one_work+0x2d8/0x504 kernel/workqueue.c:2289
worker_thread+0x340/0x610 kernel/workqueue.c:2436
kthread+0x12c/0x158 kernel/kthread.c:376
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863
prev parent reply other threads:[~2023-01-22 5:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 0:59 [syzbot] [hfs?] possible deadlock in hfs_find_init (2) syzbot
2023-01-22 5:22 ` syzbot [this message]
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=000000000000b31ed905f2d37856@google.com \
--to=syzbot+e390d66dda462b51fde1@syzkaller.appspotmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).