On Fri, 6 Dec 2024 01:04:23 +0900, Ryusuke Konishi 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? According to the log when I reproduced the problem, I analyzed that the problem occurred like this: CPU0 CPU1 ==== ==== nilfs_mkdir // file0 nilfs_new_inode // ino is 11 mount // mount file0 umount // .nilfs, ino is 11 nilfs_rmdir // ino is 11, i_size = 0, i_nlink = 0 umount // file0, ino is 11 nilfs_rmdir // ino 11, i_size = 0, i_nlink = 0, trigger warning > > 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? Are you talking about the following call trace? If so, then because the value of inode->i_state is I_DIRTY (set in nilfs_mkdir) it will not enter __nilfs_read_inode(). nilfs_iget()-> __nilfs_read_inode()-> nilfs_read_inode_common() > > Also, why do you put the i_size check as an AND condition? i_size will set to 0 in nilfs_rmdir(), so check it too. > 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. BR, Edward
