[syzbot] [nilfs?] WARNING in mark_buffer_dirty (5)

[syzbot]

Hello,

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:
Reported-by: syzbot+cdfcae...@syzkaller.appspotmail.com

------------[ 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 syzk...@googlegroups.com.

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]

syzbot has bisected this issue to:

commit 28a65b49eb53e172d23567005465019658bfdb4d
Author: Ryusuke Konishi <konishi...@gmail.com>
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

Reported-by: syzbot+cdfcae...@syzkaller.appspotmail.com
Fixes: 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

[Ryusuke Konishi]

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

Signed-off-by: Ryusuke Konishi <konishi...@gmail.com>
Reported-by: syzbot+cdfcae...@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/0000000000003d...@google.com
Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption")
Tested-by: Ryusuke Konishi <konishi...@gmail.com>
Cc: <sta...@vger.kernel.org> # 3.10+
---
fs/nilfs2/alloc.c | 3 ++-
fs/nilfs2/inode.c | 7 +++++--
2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/nilfs2/alloc.c b/fs/nilfs2/alloc.c
index 6ce8617b562d..7342de296ec3 100644
--- a/fs/nilfs2/alloc.c
+++ b/fs/nilfs2/alloc.c
@@ -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);
diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c
index 35bc79305318..acf7a266f72f 100644
--- a/fs/nilfs2/inode.c
+++ b/fs/nilfs2/inode.c
@@ -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;
}
--
2.34.1