]> git.ipfire.org Git - people/ms/linux.git/commit - fs/xfs/xfs_symlink.c
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)
commit7b7820b83f230036fc48c3e7fb280c48c58adebf
tree88e83dad60faf7781dcf00950653daf7954609d4
parent59d7fab2dff96ed2ca732168859489d71fabd33b
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