Christoph Hellwig <hch@xxxxxx> writes:
> iomap_writepage_map aready warns about inline data, but then just ignores
> it. Treat it as an error and return -EIO.
>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
> fs/iomap/buffered-io.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
The code change looks very obvious. But sorry that I have some queries
which I would like to clarify -
The dirty page we are trying to write can always belong to the dirty
inode with inline data in it right?
So it is then the FS responsibility to un-inline the inode in the
->map_blocks call is it?
Looking at the gfs2 code, it might as well return iomap->type as
IOMAP_INLINE for IOMAP_WRITE request in it's iomap_writeback_ops no?
iomap_writeback_ops -> gfs2_map_blocks -> __gfs2_iomap_get
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 98d52feb220f0a..b1bcc43baf0caf 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1818,8 +1818,10 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc,
> if (error)
> break;
> trace_iomap_writepage_map(inode, &wpc->iomap);
> - if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE))
> - continue;
> + if (WARN_ON_ONCE(wpc->iomap.type == IOMAP_INLINE)) {
> + error = -EIO;
> + break;
> + }
> if (wpc->iomap.type == IOMAP_HOLE)
> continue;
> iomap_add_to_ioend(inode, pos, folio, ifs, wpc, wbc,
> --
> 2.39.2
-ritesh
