summaryrefslogtreecommitdiff
path: root/fs/xfs/xfs_reflink.c
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2021-12-15 12:07:41 -0800
committerDarrick J. Wong <djwong@kernel.org>2021-12-15 17:06:27 -0800
commit8d6b2944fec4da61f47a01da7f904775bae9b922 (patch)
tree9852640ade8b29abb2b4b6a37feef39ab40d5e87 /fs/xfs/xfs_reflink.c
parentc731eaadcf432ccb423384a5fb06c24707a22a28 (diff)
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>
Diffstat (limited to 'fs/xfs/xfs_reflink.c')
0 files changed, 0 insertions, 0 deletions