On 12/05/2025 16:43, Christoph Hellwig wrote:
> xfs_zone_gc_write_chunk writes out the data buffer read in earlier using
> the same bio, and currenly looks at bv_offset for the offset into the
> scratch folio for that. But commit 26064d3e2b4d ("block: fix adding
> folio to bio") changed how bv_page and bv_offset are calculated for
> adding larger folios, breaking this fragile logic.
>
> Switch to extracting the full physical address from the old bio_vec,
> and calculate the offset into the folio from that instead.
>
> This fixes data corruption during garbage collection with heavy rockdsb
> workloads. Thanks to Hans for tracking down the culprit commit during
> long bisection sessions.
>
> Fixes: 26064d3e2b4d ("block: fix adding folio to bio")
> Fixes: 080d01c41d44 ("xfs: implement zoned garbage collection")
> Reported-by: Hans Holmberg <Hans.Holmberg@xxxxxxx>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
> fs/xfs/xfs_zone_gc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_zone_gc.c b/fs/xfs/xfs_zone_gc.c
> index 8c541ca71872..a045b1dedd68 100644
> --- a/fs/xfs/xfs_zone_gc.c
> +++ b/fs/xfs/xfs_zone_gc.c
> @@ -801,7 +801,8 @@ xfs_zone_gc_write_chunk(
> {
> struct xfs_zone_gc_data *data = chunk->data;
> struct xfs_mount *mp = chunk->ip->i_mount;
> - unsigned int folio_offset = chunk->bio.bi_io_vec->bv_offset;
> + phys_addr_t bvec_paddr =
> + bvec_phys(bio_first_bvec_all(&chunk->bio));
> struct xfs_gc_bio *split_chunk;
>
> if (chunk->bio.bi_status)
> @@ -816,7 +817,7 @@ xfs_zone_gc_write_chunk(
>
> bio_reset(&chunk->bio, mp->m_rtdev_targp->bt_bdev, REQ_OP_WRITE);
> bio_add_folio_nofail(&chunk->bio, chunk->scratch->folio, chunk->len,
> - folio_offset);
> + offset_in_folio(chunk->scratch->folio, bvec_paddr));
>
> while ((split_chunk = xfs_zone_gc_split_write(data, chunk)))
> xfs_zone_gc_submit_write(data, split_chunk);
Looks good and fixes the gc data corruption issue, thanks!
Reviewed-by: Hans Holmberg <Hans.Holmberg@xxxxxxx>
Tested-by: Hans Holmberg <Hans.Holmberg@xxxxxxx>
