Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 38e2299a authored by David Chinner's avatar David Chinner Committed by Nathan Scott
Browse files

[XFS] Explain the race closed by the addition of vn_iowait() to the start 


of xfs_itruncate_start().

SGI-PV: 947420
SGI-Modid: xfs-linux-melb:xfs-kern:25527a

Signed-off-by: default avatarDavid Chinner <dgc@sgi.com>
Signed-off-by: default avatarNathan Scott <nathans@sgi.com>
parent 9fa8046f

fs/xfs/xfs_inode.c

+10 −0
Original line number Original line Diff line number Diff line
@@ -1393,6 +1393,16 @@ xfs_itrunc_trace( 
 * calling into the buffer/page cache code and we can't hold the

 * calling into the buffer/page cache code and we can't hold the

 * inode lock when we do so.

 * inode lock when we do so.

 *

 *

 * We need to wait for any direct I/Os in flight to complete before we

 * proceed with the truncate. This is needed to prevent the extents

 * being read or written by the direct I/Os from being removed while the

 * I/O is in flight as there is no other method of synchronising

 * direct I/O with the truncate operation.  Also, because we hold

 * the IOLOCK in exclusive mode, we prevent new direct I/Os from being

 * started until the truncate completes and drops the lock. Essentially,

 * the vn_iowait() call forms an I/O barrier that provides strict ordering

 * between direct I/Os and the truncate operation.

 *

 * The flags parameter can have either the value XFS_ITRUNC_DEFINITE

 * The flags parameter can have either the value XFS_ITRUNC_DEFINITE

 * or XFS_ITRUNC_MAYBE.  The XFS_ITRUNC_MAYBE value should be used

 * or XFS_ITRUNC_MAYBE.  The XFS_ITRUNC_MAYBE value should be used

 * in the case that the caller is locking things out of order and

 * in the case that the caller is locking things out of order and