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