WARNING in mark_buffer_dirty (5)
Subsystems (2)
syzbot
syzbotHello,
syzbot found the following issue on:
HEAD commit: 5f63595ebd82 Merge tag 'input-for-v6.4-rc5' of git://git.k.. git tree: upstream console+strace: https://syzkaller.appspot.com/x/log.txt?x=1095a51b280000 kernel config: https://syzkaller.appspot.com/x/.config?x=7474de833c217bf4 dashboard link: https://syzkaller.appspot.com/bug?extid=cdfcae656bac88ba0e2d compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a18595280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=141c5463280000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d12b9e46ffe8/disk-5f63595e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/c9044ded7edd/vmlinux-5f63595e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/09f0fd3926e8/bzImage-5f63595e.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/1f3799cb13b4/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
------------[ cut here ]------------ WARNING: CPU: 1 PID: 5085 at fs/buffer.c:1130 mark_buffer_dirty+0x2dd/0x500 Modules linked in: CPU: 1 PID: 5085 Comm: syz-executor134 Not tainted 6.4.0-rc5-syzkaller-00024-g5f63595ebd82 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 RIP: 0010:mark_buffer_dirty+0x2dd/0x500 fs/buffer.c:1130 Code: df e8 57 0e e0 ff 48 8b 3b be 04 00 00 00 5b 41 5c 41 5e 41 5f 5d e9 22 69 fc ff e8 3d 39 88 ff e9 71 ff ff ff e8 33 39 88 ff <0f> 0b e9 6d fd ff ff e8 27 39 88 ff 0f 0b e9 96 fd ff ff e8 1b 39 RSP: 0018:ffffc90003f5f810 EFLAGS: 00010293
RAX: ffffffff820345fd RBX: ffff8880775fbb01 RCX: ffff888015f30000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffffffff82034364 R09: ffffed100eeb48af R10: 0000000000000000 R11: dffffc0000000001 R12: ffff8880775a4570 R13: dffffc0000000000 R14: ffffc90003f5f880 R15: 1ffff920007ebf10 FS: 0000555556a02300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000002ba98000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __nilfs_mark_inode_dirty+0x105/0x280 fs/nilfs2/inode.c:1115 nilfs_dirty_inode+0x164/0x200 fs/nilfs2/inode.c:1148 __mark_inode_dirty+0x305/0xd90 fs/fs-writeback.c:2424 mark_inode_dirty include/linux/fs.h:2144 [inline] generic_write_end+0x184/0x1e0 fs/buffer.c:2257 nilfs_write_end+0x85/0xf0 fs/nilfs2/inode.c:280 generic_perform_write+0x3ed/0x5e0 mm/filemap.c:3934 __generic_file_write_iter+0x29b/0x400 mm/filemap.c:4019 generic_file_write_iter+0xaf/0x310 mm/filemap.c:4083 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x790/0xb20 fs/read_write.c:584 ksys_write+0x1a0/0x2c0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f417000db39 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 11 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd6c282ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f417000db39 RDX: 0000000000000018 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 00007ffd6c282f00 R09: 00007ffd6c282f00 R10: 00007ffd6c282f00 R11: 0000000000000246 R12: 00007ffd6c282efc R13: 00007ffd6c282f30 R14: 00007ffd6c282f10 R15: 0000000000000006 </TASK>
---
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-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the bug is already fixed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to change bug's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the bug is a duplicate of another bug, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
syzbot
syzbotsyzbot has bisected this issue to:
syzbot has bisected this issue to:
commit 28a65b49eb53e172d23567005465019658bfdb4d
Author: Ryusuke Konishi <[email protected]> Date: Thu Apr 27 01:15:26 2023 +0000
nilfs2: do not write dirty data after degenerating to read-only
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11c5be4ba80000 start commit: 6eaae1980760 Linux 6.5-rc3 git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=13c5be4ba80000 console output: https://syzkaller.appspot.com/x/log.txt?x=15c5be4ba80000 kernel config: https://syzkaller.appspot.com/x/.config?x=5d10d93e1ae1f229 dashboard link: https://syzkaller.appspot.com/bug?extid=cdfcae656bac88ba0e2d syz repro: https://syzkaller.appspot.com/x/repro.syz?x=127ac14ea80000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1693a06ea80000
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Ryusuke Konishi
maintainerPATCH 1/1 nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse
In reply to syzbotA syzbot stress test using a corrupted disk image reported that mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can panic if the kernel is booted with panic_on_warn.
This is because nilfs2 keeps buffer pointers in local structures for some metadata and reuses them, but such buffers may be forcibly discarded by nilfs_clear_dirty_page() in some critical situations.
This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only"), but the issue has potentially existed before.
Fix this issue by checking the uptodate flag when attempting to reuse an internally held buffer, and reloading the metadata instead of reusing the buffer if the flag was lost.
--- fs/nilfs2/alloc.c | 3 ++- fs/nilfs2/inode.c | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-)
fs/nilfs2/alloc.c +2 -1
@@ -205,7 +205,8 @@ static int nilfs_palloc_get_block(struct inode *inode, unsigned long blkoff,int ret;spin_lock (lock); -if (prev->bh && blkoff == prev->blkoff) { +if (prev->bh && blkoff == prev->blkoff && +likely (buffer_uptodate (prev->bh))) {get_bh (prev->bh); *bhp = prev->bh;spin_unlock (lock);
fs/nilfs2/inode.c +5 -2
@@ -1025,7 +1025,7 @@ int nilfs_load_inode_block(struct inode *inode, struct buffer_head **pbh)int err;spin_lock (&nilfs->ns_inode_lock); -if (ii->i_bh ==NULL ) { +if (ii->i_bh ==NULL ||unlikely (!buffer_uptodate (ii->i_bh))) {spin_unlock (&nilfs->ns_inode_lock); err =nilfs_ifile_get_inode_block (ii->i_root->ifile, inode->i_ino, pbh);
@@ -1034,7 +1034,10 @@ int nilfs_load_inode_block(struct inode *inode, struct buffer_head **pbh)spin_lock (&nilfs->ns_inode_lock);if (ii->i_bh ==NULL ) ii->i_bh = *pbh; -else { +else if (unlikely (!buffer_uptodate (ii->i_bh))) { +__brelse (ii->i_bh); + ii->i_bh = *pbh; + }else {brelse (*pbh); *pbh = ii->i_bh; }
Signature · 1 line
2.34.1