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: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>

diff --git a/fs/xfs/xfs_zone_alloc.c b/fs/xfs/xfs_zone_alloc.c
index 23cdab4515bb2cb062a49fc04e8f784d72f0c4c1..0404022408078bf6bdd07c3f31edfca78b5be13f 100644 (file)
--- a/fs/xfs/xfs_zone_alloc.c
+++ b/fs/xfs/xfs_zone_alloc.c
@@ -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)