mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-07-16 15:39:42 -04:00
Code Issues Packages Projects Releases Wiki Activity

xfs: document another racy GC case in xfs_zoned_map_extent

Browse Source 
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>
This commit is contained in:
Christoph Hellwig
2025-10-23 17:17:03 +02:00
committed by Carlos Maiolino
parent 83bac569c7
commit 0db22d7ee4
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
fs/xfs/xfs_zone_alloc.c
View File

@@ -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)