]> www.infradead.org Git - users/jedix/linux-maple.git/commit
xfs: don't call remap_verify_area with sb write protection held
authorChristoph Hellwig <hch@lst.de>
Wed, 22 Jan 2025 05:43:21 +0000 (06:43 +0100)
committerCarlos Maiolino <cem@kernel.org>
Fri, 24 Jan 2025 11:08:50 +0000 (12:08 +0100)
commitf5f0ed89f13e3e5246404a322ee85169a226bfb5
tree1444313bd1d759355bd44ee6a09a430ce42e48eb
parent89841b23809f5fb12cbead142204064739fef25a
xfs: don't call remap_verify_area with sb write protection held

The XFS_IOC_EXCHANGE_RANGE ioctl with the XFS_EXCHANGE_RANGE_TO_EOF flag
operates on a range bounded by the end of the file.  This means the
actual amount of blocks exchanged is derived from the inode size, which
is only stable with the IOLOCK (i_rwsem) held.  Do that, it currently
calls remap_verify_area from inside the sb write protection which nests
outside the IOLOCK.  But this makes fsnotify_file_area_perm which is
called from remap_verify_area unhappy when the kernel is built with
lockdep and the recently added CONFIG_FANOTIFY_ACCESS_PERMISSIONS
option.

Fix this by always calling remap_verify_area before taking the write
protection, and passing a 0 size to remap_verify_area similar to
the FICLONE/FICLONERANGE ioctls when they are asked to clone until
the file end.

(Note: the size argument gets passed to fsnotify_file_area_perm, but
then isn't actually used there).

Fixes: 9a64d9b3109d ("xfs: introduce new file range exchange ioctl")
Cc: <stable@vger.kernel.org> # v6.10
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
fs/xfs/xfs_exchrange.c