From: David Sterba <dsterba@suse.cz>
To: syzbot <syzbot+e017b58b47bacf31a06b@syzkaller.appspotmail.com>
Cc: clm@fb.com, dsterba@suse.com, josef@toxicpanda.com,
linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [btrfs?] kernel BUG in mapping_try_invalidate
Date: Wed, 15 May 2024 19:02:16 +0200 [thread overview]
Message-ID: <20240515170216.GU4449@twin.jikos.cz> (raw)
In-Reply-To: <000000000000f6c32a0610c6af48@google.com>
On Wed, Feb 07, 2024 at 12:43:22AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 99bd3cb0d12e Merge tag 'bcachefs-2024-02-05' of https://ev..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16629540180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=89a5d896b14c4565
> dashboard link: https://syzkaller.appspot.com/bug?extid=e017b58b47bacf31a06b
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/73aa72bd3577/disk-99bd3cb0.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/6c6bf1614995/vmlinux-99bd3cb0.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/7df252d11788/bzImage-99bd3cb0.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+e017b58b47bacf31a06b@syzkaller.appspotmail.com
>
> process_one_work kernel/workqueue.c:2633 [inline]
> process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706
> worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787
> kthread+0x2ef/0x390 kernel/kthread.c:388
> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
> ------------[ cut here ]------------
> kernel BUG at mm/filemap.c:2072!
unsigned find_lock_entries(struct address_space *mapping, pgoff_t *start,
pgoff_t end, struct folio_batch *fbatch, pgoff_t *indices)
{
XA_STATE(xas, &mapping->i_pages, *start);
struct folio *folio;
rcu_read_lock();
while ((folio = find_get_entry(&xas, end, XA_PRESENT))) {
if (!xa_is_value(folio)) {
if (folio->index < *start)
goto put;
if (folio_next_index(folio) - 1 > end)
goto put;
if (!folio_trylock(folio))
goto put;
if (folio->mapping != mapping ||
folio_test_writeback(folio))
goto unlock;
VM_BUG_ON_FOLIO(!folio_contains(folio, xas.xa_index),
folio);
index out of range
> invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
> CPU: 1 PID: 16388 Comm: syz-executor.2 Not tainted 6.8.0-rc3-syzkaller-00005-g99bd3cb0d12e #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
> RIP: 0010:find_lock_entries+0xfdf/0x1110 mm/filemap.c:2071
> Code: e8 96 4d cb ff eb 2a e8 8f 4d cb ff eb 3a e8 88 4d cb ff eb 4a e8 81 4d cb ff 4c 89 f7 48 c7 c6 a0 41 b3 8b e8 32 0f 10 00 90 <0f> 0b e8 6a 4d cb ff 4c 89 f7 48 c7 c6 a0 4b b3 8b e8 1b 0f 10 00
> RSP: 0018:ffffc90013457520 EFLAGS: 00010246
> RAX: f6dc7e6d18066c00 RBX: 0000000000000000 RCX: ffffc90013457303
> RDX: 0000000000000002 RSI: ffffffff8baac6e0 RDI: ffffffff8bfd93e0
> RBP: ffffc90013457670 R08: ffffffff8f842b6f R09: 1ffffffff1f0856d
> R10: dffffc0000000000 R11: fffffbfff1f0856e R12: ffffc900134575c0
> R13: ffffffffffffffff R14: ffffea0000b3c100 R15: ffffea0000b3c134
> FS: 00007f60b3b6e6c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000056197e1c4648 CR3: 000000007d35c000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> mapping_try_invalidate+0x162/0x640 mm/truncate.c:499
> open_ctree+0xa9c/0x2a00 fs/btrfs/disk-io.c:3220
An initial and unconditional
invalidate_bdev(fs_devices->latest_dev->bdev);
Looks like our block device structures are valid, so possibly the memory
related structures are wrong. Could be inherited from previous runs of
the reproducer or because of previous errors in the driver. The console
log has some IO errors and loop device size changes, that would point
towards loop device.
#syz set subsystems: block
prev parent reply other threads:[~2024-05-15 17:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 8:43 [syzbot] [btrfs?] kernel BUG in mapping_try_invalidate syzbot
2024-05-15 17:02 ` David Sterba [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=20240515170216.GU4449@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+e017b58b47bacf31a06b@syzkaller.appspotmail.com \
--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 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 read-only IMAP folder(s) and NNTP newsgroup(s).