All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.