Re: [PATCH 02/13] iomap: treat inline data in iomap_writepage_map as an I/O error

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

Christoph Hellwig <hch@lst.de> 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@lst.de>
> ---
>  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