]> git.baikalelectronics.ru Git - kernel.git/commit
xfs: don't expose internal symlink metadata buffers to the vfs
authorDarrick J. Wong <djwong@kernel.org>
Wed, 15 Dec 2021 20:07:41 +0000 (12:07 -0800)
committerDarrick J. Wong <djwong@kernel.org>
Tue, 21 Dec 2021 17:49:41 +0000 (09:49 -0800)
commita36540a79311117c06c19c28419c63454d7bf33b
tree88e83dad60faf7781dcf00950653daf7954609d4
parent6a5259df9fc8ada1623beb545f293ce91f4db7bc
xfs: don't expose internal symlink metadata buffers to the vfs

Ian Kent reported that for inline symlinks, it's possible for
vfs_readlink to hang on to the target buffer returned by
_vn_get_link_inline long after it's been freed by xfs inode reclaim.
This is a layering violation -- we should never expose XFS internals to
the VFS.

When the symlink has a remote target, we allocate a separate buffer,
copy the internal information, and let the VFS manage the new buffer's
lifetime.  Let's adapt the inline code paths to do this too.  It's
less efficient, but fixes the layering violation and avoids the need to
adapt the if_data lifetime to rcu rules.  Clearly I don't care about
readlink benchmarks.

As a side note, this fixes the minor locking violation where we can
access the inode data fork without taking any locks; proper locking (and
eliminating the possibility of having to switch inode_operations on a
live inode) is essential to online repair coordinating repairs
correctly.

Reported-by: Ian Kent <raven@themaw.net>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
fs/xfs/xfs_iops.c
fs/xfs/xfs_symlink.c