[syzbot] [nilfs?] WARNING in nilfs_segctor_do_construct (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 9a48d6046722 x86/retbleed: Fix return thunk alignment
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=121a54ba280000
kernel config: https://syzkaller.appspot.com/x/.config?x=38526bf24c8d961b
dashboard link: https://syzkaller.appspot.com/bug?extid=33494cd0df2ec2931851
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=1438dcc6280000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=124666a2280000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/9151d600da35/disk-9a48d604.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/895748ad0a36/vmlinux-9a48d604.xz
kernel image: https://storage.googleapis.com/syzbot-assets/826ceb18c361/bzImage-9a48d604.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/32bae60be5eb/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+33494c...@syzkaller.appspotmail.com

NILFS (loop1): nilfs_sufile_update: invalid segment number: 52
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5017 at fs/nilfs2/segment.c:1503 nilfs_segctor_collect fs/nilfs2/segment.c:1556 [inline]
WARNING: CPU: 0 PID: 5017 at fs/nilfs2/segment.c:1503 nilfs_segctor_do_construct+0x31e7/0x6d30 fs/nilfs2/segment.c:2070
Modules linked in:

CPU: 0 PID: 5017 Comm: segctord Not tainted 6.4.0-rc1-syzkaller-00133-g9a48d6046722 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023
RIP: 0010:nilfs_segctor_truncate_segments fs/nilfs2/segment.c:1503 [inline]
RIP: 0010:nilfs_segctor_collect fs/nilfs2/segment.c:1556 [inline]
RIP: 0010:nilfs_segctor_do_construct+0x31e7/0x6d30 fs/nilfs2/segment.c:2070
Code: ff df 80 3c 08 00 74 08 4c 89 ef e8 03 fb 93 fe 4d 8b 6d 00 4c 3b 6c 24 50 74 31 e8 13 2d 3c fe e9 39 ff ff ff e8 09 2d 3c fe <0f> 0b eb c3 44 89 e1 80 e1 07 80 c1 03 38 c1 0f 8c 44 ff ff ff 4c
RSP: 0018:ffffc90003b7f700 EFLAGS: 00010293

RAX: ffffffff834f3a37 RBX: 00000000ffffffea RCX: ffff888027728000
RDX: 0000000000000000 RSI: 00000000ffffffea RDI: 0000000000000000
RBP: ffffc90003b7fc30 R08: ffffffff834f39f5 R09: fffff5200076fe51
R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000010
R13: ffff888076756dc8 R14: dffffc0000000000 R15: ffff8880765d4e38
FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020074000 CR3: 0000000029d7c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
nilfs_segctor_construct+0x145/0x8c0 fs/nilfs2/segment.c:2404
nilfs_segctor_thread_construct fs/nilfs2/segment.c:2512 [inline]
nilfs_segctor_thread+0x53a/0x1140 fs/nilfs2/segment.c:2595
kthread+0x2b8/0x350 kernel/kthread.c:379
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
</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

[Ryusuke Konishi]

Syzbot reports that in its stress test for resize ioctl, the log writing
function nilfs_segctor_do_construct hits a WARN_ON in
nilfs_segctor_truncate_segments().

It turned out that there is a problem with the current implementation of
the resize ioctl, which changes the writable range on the device
(the range of allocatable segments) at the end of the resize process.

This order is necessary for file system expansion to avoid corrupting
the superblock at trailing edge. However, in the case of a file system
shrink, if log writes occur after truncating out-of-bounds trailing
segments and before the resize is complete, segments may be allocated
from the truncated space.

The userspace resize tool was fine as it limits the range of allocatable
segments before performing the resize, but it can run into this issue if
the resize ioctl is called alone.

Fix this issue by changing nilfs_sufile_resize() to update the range of
allocatable segments immediately after successful truncation of segment
space in case of file system shrink.

Signed-off-by: Ryusuke Konishi <konishi...@gmail.com>
Reported-by: syzbot+33494c...@syzkaller.appspotmail.com
Closes: https://lkml.kernel.org/r/00000000000054...@google.com
Fixes: 4e33f9eab07e ("nilfs2: implement resize ioctl")
Tested-by: Ryusuke Konishi <konishi...@gmail.com>
Cc: sta...@vger.kernel.org
---
fs/nilfs2/sufile.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/fs/nilfs2/sufile.c b/fs/nilfs2/sufile.c
index dc359b56fdfa..2c6078a6b8ec 100644
--- a/fs/nilfs2/sufile.c
+++ b/fs/nilfs2/sufile.c
@@ -779,6 +779,15 @@ int nilfs_sufile_resize(struct inode *sufile, __u64 newnsegs)
goto out_header;

sui->ncleansegs -= nsegs - newnsegs;
+
+ /*
+ * If the sufile is successfully truncated, immediately adjust
+ * the segment allocation space while locking the semaphore
+ * "mi_sem" so that nilfs_sufile_alloc() never allocates
+ * segments in the truncated space.
+ */
+ sui->allocmax = newnsegs - 1;
+ sui->allocmin = 0;
}

kaddr = kmap_atomic(header_bh->b_page);
--
2.34.1