Re: [PATCH RFC 1/2] iomap: prioritize iter.status error over ->iomap_end()

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

Brian Foster <bfoster@redhat.com> writes:

> Jan Kara reports that commit bc264fea0f6f subtly changed error
> handling behavior in iomap_iter() in the case where both iter.status
> and ->iomap_end() return error codes. Previously, iter.status had
> priority and would return to the caller regardless of the
> ->iomap_end() result. After the change, an ->iomap_end() error
> returns immediately.
>
> This had the unexpected side effect of enabling a DIO fallback to
> buffered write on ext4 because ->iomap_end() could return -ENOTBLK
> and overload an -EINVAL error from the core iomap direct I/O code.
>
> This has been fixed independently in ext4, but nonetheless the
> change in iomap was unintentional. Since other filesystems may use
> this in similar ways, restore long standing behavior and always
> return the value of iter.status if it happens to contain an error
> code.
>
> Fixes: bc264fea0f6f ("iomap: support incremental iomap_iter advances")
> Diagnosed-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---


Looks good to me. Please feel free to add:
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

>  fs/iomap/iter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/iomap/iter.c b/fs/iomap/iter.c
> index cef77ca0c20b..7cc4599b9c9b 100644
> --- a/fs/iomap/iter.c
> +++ b/fs/iomap/iter.c
> @@ -80,7 +80,7 @@ int iomap_iter(struct iomap_iter *iter, const struct iomap_ops *ops)
>  				iomap_length_trim(iter, iter->iter_start_pos,
>  						  olen),
>  				advanced, iter->flags, &iter->iomap);
> -		if (ret < 0 && !advanced)
> +		if (ret < 0 && !advanced && !iter->status)
>  			return ret;
>  	}
>  
> -- 
> 2.51.0