summaryrefslogtreecommitdiffstats
path: root/ax25mond/ax25mond.c
diff options
context:
space:
mode:
Diffstat (limited to 'ax25mond/ax25mond.c')
0 files changed, 0 insertions, 0 deletions
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: dump_stack+0x63/0x81 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 drop_nlink+0x3e/0x50 v9fs_remove+0xaa/0x130 [9p] v9fs_vfs_rmdir+0x13/0x20 [9p] vfs_rmdir+0xb7/0x130 do_rmdir+0x1b8/0x230 SyS_unlinkat+0x22/0x30 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@linux.alibaba.com Signed-off-by: Eryu Guan <eguan@linux.alibaba.com> Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com> Tested-by: Roman Kapl <code@rkapl.cz> Cc: Caspar Zhang <caspar@linux.alibaba.com> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@sandia.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Cc: <v9fs-developer@lists.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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:
    dump_stack+0x63/0x81
    __warn+0xcb/0xf0
    warn_slowpath_null+0x1d/0x20
    drop_nlink+0x3e/0x50
    v9fs_remove+0xaa/0x130 [9p]
    v9fs_vfs_rmdir+0x13/0x20 [9p]
    vfs_rmdir+0xb7/0x130
    do_rmdir+0x1b8/0x230
    SyS_unlinkat+0x22/0x30
    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@linux.alibaba.com
Signed-off-by: Eryu Guan <eguan@linux.alibaba.com>
Reviewed-by: Yiwen Jiang <jiangyiwen@huawei.com>
Tested-by: Roman Kapl <code@rkapl.cz>
Cc: Caspar Zhang <caspar@linux.alibaba.com>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Ron Minnich <rminnich@sandia.gov>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: <v9fs-developer@lists.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/9p: Compare qid.path in v9fs_test_inode 2017-10-24T03:10:01+00:00 Tuomas Tynkkynen tuomas@tuxera.com 2017-09-06T14:59:07+00:00 8ee031631546cf2f7859cc69593bd60bbdd70b46 Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked() instead of iget_locked(). However, the test() callback is not checking fid.path at all, which means that a lookup in the inode cache can now accidentally locate a completely wrong inode from the same inode hash bucket if the other fields (qid.type and qid.version) match. Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") Cc: stable@vger.kernel.org Reviewed-by: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details
and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked()
instead of iget_locked(). However, the test() callback is not checking
fid.path at all, which means that a lookup in the inode cache can now
accidentally locate a completely wrong inode from the same inode hash
bucket if the other fields (qid.type and qid.version) match.

Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.")
Cc: stable@vger.kernel.org
Reviewed-by: Latchesar Ionkov <lucho@ionkov.net>
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>