]> www.infradead.org Git - users/hch/misc.git/commit
xfs: don't call remap_verify_area with sb write protection held
authorChristoph Hellwig <hch@lst.de>
Sun, 19 Jan 2025 06:02:36 +0000 (07:02 +0100)
committerChristoph Hellwig <hch@lst.de>
Mon, 3 Feb 2025 09:18:36 +0000 (10:18 +0100)
commit99ac624d9c3db214536c658098c37ef463e79027
tree5d07678ed92af69cb9f66b57d9355188279f6375
parent2014c95afecee3e76ca4a56956a936e23283f05b
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")
Signed-off-by: Christoph Hellwig <hch@lst.de>
fs/xfs/xfs_exchrange.c