On Wed, Feb 26, 2025 at 11:51:19AM -0500, Goldwyn Rodrigues wrote:
> If the current ioend is built for iomap with flags set to
> IOMAP_F_BOUNDARY and the next iomap does not have IOMAP_F_BOUNDARY set,
> IOMAP_F_BOUNDARY will not be respected because the iomap structure has
> been overwritten during the map_blocks call for the next iomap. Fix this
> by checking both iomap.flags and ioend->io_flags for IOMAP_F_BOUNDARY.
Why is it necessary to avoid merging with an IOMAP_F_BOUNDARY ioend if
this new mapping isn't IOMAP_F_BOUNDARY? If the filesystem needs that,
it can set BOUNDARY on both mappings, right?
--D
> Fixes: 64c58d7c9934 ("iomap: add a merge boundary flag")
> Signed-off-by: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx>
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index d303e6c8900c..0e2d24581bd3 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1739,7 +1739,8 @@ static struct iomap_ioend *iomap_alloc_ioend(struct iomap_writepage_ctx *wpc,
>
> static bool iomap_can_add_to_ioend(struct iomap_writepage_ctx *wpc, loff_t pos)
> {
> - if (wpc->iomap.offset == pos && (wpc->iomap.flags & IOMAP_F_BOUNDARY))
> + if (wpc->iomap.offset == pos &&
> + ((wpc->iomap.flags | wpc->ioend->io_flags) & IOMAP_F_BOUNDARY))
> return false;
> if ((wpc->iomap.flags & IOMAP_F_SHARED) !=
> (wpc->ioend->io_flags & IOMAP_F_SHARED))
>
> --
> Goldwyn
>
