Skip to contentSkip to conversation

Wait for all I/O on truncate to zero file size

PATCH In review Lachlan McIlroy 2 participants 2 messages Sep 23, 2008 – Sep 24, 2008 XFS filesystem

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Wait for all I/O on truncate to zero file size

It's possible to have outstanding xfs_ioend_t's queued when the file size is zero. This can happen in the direct I/O path when a direct I/O write fails due to ENOSPC. In this case the xfs_ioend_t will still be queued (ie xfs_end_io_direct() does not know that the I/O failed so can't force the xfs_ioend_t to be flushed synchronously).

When we truncate a file on unlink we don't know to wait for these xfs_ioend_ts and we can have a use-after-free situation if the inode is reclaimed before the xfs_ioend_t is finally processed.

As was suggested by Dave Chinner lets wait for all I/Os to complete when truncating the file size to zero.

fs/xfs/xfs_inode.c +0 -0
@@ -1449,7 +1449,7 @@ xfs_itruncate_start(
	mp = ip->i_mount;

	/* wait for the completion of any pending DIOs */
-	if (new_size < ip->i_size)
+	if (new_size == 0 || new_size < ip->i_size)
		vn_iowait(ip);

	/*
#1 lore raw
Quoted 6 lines · Lachlan McIlroy

It's possible to have outstanding xfs_ioend_t's queued when the file size is zero. This can happen in the direct I/O path when a direct I/O write fails due to ENOSPC. In this case the xfs_ioend_t will still be queued (ie xfs_end_io_direct() does not know that the I/O failed so can't force the xfs_ioend_t to be flushed synchronously).

Quoted 6 lines

When we truncate a file on unlink we don't know to wait for these xfs_ioend_ts and we can have a use-after-free situation if the inode is reclaimed before the xfs_ioend_t is finally processed.

As was suggested by Dave Chinner lets wait for all I/Os to complete when truncating the file size to zero.

Looks good.