Commit 0db22d7e authored by Christoph Hellwig's avatar Christoph Hellwig Committed by Carlos Maiolino
Browse files

xfs: document another racy GC case in xfs_zoned_map_extent 



Besides blocks being invalidated, there is another case when the original
mapping could have changed between querying the rmap for GC and calling
xfs_zoned_map_extent.  Document it there as it took us quite some time
to figure out what is going on while developing the multiple-GC
protection fix.

Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarHans Holmberg <hans.holmberg@wdc.com>
Reviewed-by: default avatarDamien Le Moal <dlemoal@kernel.org>
Reviewed-by: default avatarCarlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
Signed-off-by: default avatarCarlos Maiolino <cem@kernel.org>
parent 83bac569

fs/xfs/xfs_zone_alloc.c

+8 −0
Original line number Diff line number Diff line
@@ -246,6 +246,14 @@ xfs_zoned_map_extent( 
	 * If a data write raced with this GC write, keep the existing data in

	 * the data fork, mark our newly written GC extent as reclaimable, then

	 * move on to the next extent.

	 *

	 * Note that this can also happen when racing with operations that do

	 * not actually invalidate the data, but just move it to a different

	 * inode (XFS_IOC_EXCHANGE_RANGE), or to a different offset inside the

	 * inode (FALLOC_FL_COLLAPSE_RANGE / FALLOC_FL_INSERT_RANGE).  If the

	 * data was just moved around, GC fails to free the zone, but the zone

	 * becomes a GC candidate again as soon as all previous GC I/O has

	 * finished and these blocks will be moved out eventually.

	 */

	if (old_startblock != NULLFSBLOCK &&

	    old_startblock != data.br_startblock)