On Thu, Dec 5, 2024 at 9:26 PM Edward Adam Davis wrote: > > syzbot reported a WARNING in nilfs_rmdir. [1] > > The inode is used twice by the same task to unmount and remove directories > ".nilfs" and "file0", it trigger warning in nilfs_rmdir. > > Avoid to this issue, check i_size and i_nlink in nilfs_iget(), if they are > both 0, it means that this inode has been removed, and iput is executed to > reclaim it. > > [1] > WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407 > Modules linked in: > CPU: 1 UID: 0 PID: 5824 Comm: syz-executor223 Not tainted 6.12.0-syzkaller-12113-gbcc8eda6d349 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 > RIP: 0010:drop_nlink+0xc4/0x110 fs/inode.c:407 > Code: bb 70 07 00 00 be 08 00 00 00 e8 57 0b e6 ff f0 48 ff 83 70 07 00 00 5b 41 5c 41 5e 41 5f 5d c3 cc cc cc cc e8 9d 4c 7e ff 90 <0f> 0b 90 eb 83 44 89 e1 80 e1 07 80 c1 03 38 c1 0f 8c 5c ff ff ff > RSP: 0018:ffffc900037f7c70 EFLAGS: 00010293 > RAX: ffffffff822124a3 RBX: 1ffff1100e7ae034 RCX: ffff88807cf53c00 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: 0000000000000000 R08: ffffffff82212423 R09: 1ffff1100f8ba8ee > R10: dffffc0000000000 R11: ffffed100f8ba8ef R12: ffff888073d701a0 > R13: 1ffff1100e79f5c4 R14: ffff888073d70158 R15: dffffc0000000000 > FS: 0000555558d1e480(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000555558d37878 CR3: 000000007d920000 CR4: 00000000003526f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 > vfs_rmdir+0x3a3/0x510 fs/namei.c:4394 > do_rmdir+0x3b5/0x580 fs/namei.c:4453 > __do_sys_rmdir fs/namei.c:4472 [inline] > __se_sys_rmdir fs/namei.c:4470 [inline] > __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Reported-and-tested-by: syzbot+9260555647a5132edd48@xxxxxxxxxxxxxxxxxxxxxxxxx > Closes: https://syzkaller.appspot.com/bug?extid=9260555647a5132edd48 > Signed-off-by: Edward Adam Davis <eadavis@xxxxxx> > --- > fs/nilfs2/inode.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/fs/nilfs2/inode.c b/fs/nilfs2/inode.c > index cf9ba481ae37..254a5e46f8ea 100644 > --- a/fs/nilfs2/inode.c > +++ b/fs/nilfs2/inode.c > @@ -544,8 +544,15 @@ struct inode *nilfs_iget(struct super_block *sb, struct nilfs_root *root, > inode = nilfs_iget_locked(sb, root, ino); > if (unlikely(!inode)) > return ERR_PTR(-ENOMEM); > - if (!(inode->i_state & I_NEW)) > + > + if (!(inode->i_state & I_NEW)) { > + if (!inode->i_size && !inode->i_nlink) { > + make_bad_inode(inode); > + iput(inode); > + return ERR_PTR(-EIO); > + } > return inode; > + } > > err = __nilfs_read_inode(sb, root, ino, inode); > if (unlikely(err)) { > -- > 2.47.0 Thank you Edward. This fix seems good except for the i_size check, but I think we need to look into what's going on a bit more. I was unable to work for a while due to machine trouble, so I'd like to know if you have made any progress on your investigation. First, is this caused by a corrupted filesystem image? Or is it that the directories or files with the same inode number were generated during the namespace operations (due to a timing issue or something), and could this problem occur even if the original filesystem image is normal? When I mounted the mount_0 image as read-only, the filesystem looked normal without such inode duplication. At least, nilfs_read_inode_common(), which reads inodes from block devices, is implemented to return an error with -ESTALE if i_nlink == 0. So it seems that nilfs_iget() picked up this inode with i_nlilnk == 0 because it hit an inode being deleted in the inode cache. Why is that happening? Also, why do you put the i_size check as an AND condition? i_size is independent of i_nlink and the inode lifecycles. If i_size is also broken, this check will not work properly. If something is not working and you have included it as a workaround, I would like to know about it. Thanks, Ryusuke Konishi
