The patch titled
Subject: [PATCH] 9p: don't maintain dir i_nlink if the exported fs doesn't either
has been added to the -mm tree. Its filename is
9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Eryu Guan <eguan@xxxxxxxxxxxxxxxxx>
Subject: [PATCH] 9p: don't maintain dir i_nlink if the exported fs doesn't either
If the exported filesystem dir on 9p server doesn't maintain accurate
i_nlink count, e.g. always reports i_nlink as 1, then 9p should not
maintain nlink count either, otherwise drop_link would report warning
with i_nlink being zero.
For example:
- overlayfs sets nlink to 1 for merged dir
- ext4 (with dir_nlink feature enabled) sets nlink to 1 if a dir has
more than EXT4_LINK_MAX (65000) links.
In this case, everytime a stat(2) call (getattr) on such exported dirs
on 9p client side, the i_nlink gets reset to 1, then operations like
rmdir(2), unlink(2) and rename(2) would cause the dir nlink to go to
zero (then negative), which results in warnings in drop_nlink() and/or
inc_nlink() calls.
This can be reproduced easily as the following steps:
- export a merged overlayfs dir via qemu virtfs to guest
- mount the exported virtfs in guest
- create two sub-directories in the root dir of the mounted 9pfs
- stat the root dir of 9pfs, this resets nlink to 1
- remove all subdirs, the second unlink/rmdir would trigger warning
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1284 at fs/inode.c:282 drop_nlink+0x3e/0x50
...
Call Trace:
[<ffffffff81384042>] dump_stack+0x63/0x81
[<ffffffff81088fcb>] __warn+0xcb/0xf0
[<ffffffff810890fd>] warn_slowpath_null+0x1d/0x20
[<ffffffff8126177e>] drop_nlink+0x3e/0x50
[<ffffffffa049ca4a>] v9fs_remove+0xaa/0x130 [9p]
[<ffffffffa049cb03>] v9fs_vfs_rmdir+0x13/0x20 [9p]
[<ffffffff81251377>] vfs_rmdir+0xb7/0x130
[<ffffffff812558d8>] do_rmdir+0x1b8/0x230
[<ffffffff81256742>] SyS_unlinkat+0x22/0x30
[<ffffffff81003c17>] do_syscall_64+0x67/0x180
---[ end trace 43758d8ba91e603b ]---
Fix it by leaving i_nlink to be 1 and don't drop nlink if a directory
has nlink <= 2, which indicates that the underlying exported fs doesn't
maintain nlink count accurately. This follows what ext4 does in
ext4_dec_count().
Link: http://lkml.kernel.org/r/20180312053829.4367-1-eguan@xxxxxxxxxxxxxxxxx
Signed-off-by: Eryu Guan <eguan@xxxxxxxxxxxxxxxxx>
Reviewed-by: Yiwen Jiang <jiangyiwen@xxxxxxxxxx>
Tested-by: Roman Kapl <code@xxxxxxxx>
Cc: Caspar Zhang <caspar@xxxxxxxxxxxxxxxxx>
Cc: Eric Van Hensbergen <ericvh@xxxxxxxxx>
Cc: Ron Minnich <rminnich@xxxxxxxxxx>
Cc: Latchesar Ionkov <lucho@xxxxxxxxxx>
Cc: <v9fs-developer@xxxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
diff -puN fs/9p/vfs_inode.c~9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either fs/9p/vfs_inode.c
--- a/fs/9p/vfs_inode.c~9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either
+++ a/fs/9p/vfs_inode.c
@@ -579,6 +579,24 @@ static int v9fs_at_to_dotl_flags(int fla
}
/**
+ * v9fs_dec_count - helper functon to drop i_nlink.
+ *
+ * If a directory had nlink <= 2 (including . and ..), then we should not drop
+ * the link count, which indicates the underlying exported fs doesn't maintain
+ * nlink accurately. e.g.
+ * - overlayfs sets nlink to 1 for merged dir
+ * - ext4 (with dir_nlink feature enabled) sets nlink to 1 if a dir has more
+ * than EXT4_LINK_MAX (65000) links.
+ *
+ * @inode: inode whose nlink is being dropped
+ */
+static void v9fs_dec_count(struct inode *inode)
+{
+ if (!S_ISDIR(inode->i_mode) || inode->i_nlink > 2)
+ drop_nlink(inode);
+}
+
+/**
* v9fs_remove - helper function to remove files and directories
* @dir: directory inode that is being deleted
* @dentry: dentry that is being deleted
@@ -621,9 +639,9 @@ static int v9fs_remove(struct inode *dir
*/
if (flags & AT_REMOVEDIR) {
clear_nlink(inode);
- drop_nlink(dir);
+ v9fs_dec_count(dir);
} else
- drop_nlink(inode);
+ v9fs_dec_count(inode);
v9fs_invalidate_inode_attr(inode);
v9fs_invalidate_inode_attr(dir);
@@ -1024,12 +1042,12 @@ clunk_newdir:
if (S_ISDIR(new_inode->i_mode))
clear_nlink(new_inode);
else
- drop_nlink(new_inode);
+ v9fs_dec_count(new_inode);
}
if (S_ISDIR(old_inode->i_mode)) {
if (!new_inode)
inc_nlink(new_dir);
- drop_nlink(old_dir);
+ v9fs_dec_count(old_dir);
}
v9fs_invalidate_inode_attr(old_inode);
v9fs_invalidate_inode_attr(old_dir);
_
Patches currently in -mm which might be from eguan@xxxxxxxxxxxxxxxxx are
9p-dont-maintain-dir-i_nlink-if-the-exported-fs-doesnt-either.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
