Skip to contentSkip to conversation

Don't do I/O beyond eof when unreserving space

PATCH Superseded Lachlan McIlroy 2 participants 2 messages Sep 2, 2008 XFS filesystem

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Don't do I/O beyond eof when unreserving space

When unreserving space with boundaries that are not block aligned we round up the start and round down the end boundaries and then use this function, xfs_zero_remaining_bytes(), to zero the parts of the blocks that got dropped during the rounding. The problem is we don't consider if these blocks are beyond eof. Worse still is if we encounter delayed allocations beyond eof we will try to use the magic delayed allocation block number as a real block number. If the file size is ever extended to expose these blocks then we'll go through xfs_zero_eof() to zero them anyway.

fs/xfs/xfs_vnodeops.c +0 -0
@@ -3176,6 +3176,12 @@ xfs_zero_remaining_bytes(
	int			nimap;
	int			error = 0;

+ if (startoff >= ip->i_size)
+ return 0;
+
+ if (endoff > ip->i_size)
+ endoff = ip->i_size;
+

	bp = xfs_buf_get_noaddr(mp->m_sb.sb_blocksize,
				XFS_IS_REALTIME_INODE(ip) ?
				mp->m_rtdev_targp : mp->m_ddev_targp);
#1 lore raw
Quoted 8 lines · Lachlan McIlroy

When unreserving space with boundaries that are not block aligned we round up the start and round down the end boundaries and then use this function, xfs_zero_remaining_bytes(), to zero the parts of the blocks that got dropped during the rounding. The problem is we don't consider if these blocks are beyond eof. Worse still is if we encounter delayed allocations beyond eof we will try to use the magic delayed allocation block number as a real block number. If the file size is ever extended to expose these blocks then we'll go through xfs_zero_eof() to zero them anyway.

Makes sense. Would be nice to have a comment above the check explaining why these first strange checks are there. Something like the first setence of the patch description here.