Re: [PATCH v2] iomap: fix inline data on buffered read

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 19, 2025 at 04:51:25PM +0800, Gao Xiang wrote:
> Previously, iomap_readpage_iter() returning 0 would break out of the
> loops of iomap_readahead_iter(), which is what iomap_read_inline_data()
> relies on.
> 
> However, commit d9dc477ff6a2 ("iomap: advance the iter directly on
> buffered read") changes this behavior without calling
> iomap_iter_advance(), which causes EROFS to get stuck in
> iomap_readpage_iter().
> 
> It seems iomap_iter_advance() cannot be called in
> iomap_read_inline_data() because of the iomap_write_begin() path, so
> handle this in iomap_readpage_iter() instead.
> 
> Reported-and-tested-by: Bo Liu <liubo03@xxxxxxxxxx>
> Fixes: d9dc477ff6a2 ("iomap: advance the iter directly on buffered read")
> Cc: Brian Foster <bfoster@xxxxxxxxxx>
> Cc: Christoph Hellwig <hch@xxxxxx>
> Cc: "Darrick J. Wong" <djwong@xxxxxxxxxx>
> Cc: Christian Brauner <brauner@xxxxxxxxxx>
> Signed-off-by: Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx>
> ---

Ugh. I'd hoped ext4 testing would have uncovered such an issue, but now
that I think of it, IIRC ext4 isn't fully on iomap yet so wouldn't have
provided this coverage. So apologies for the testing oversight on my
part and thanks for the fix.

For future reference, do you guys have any documentation or whatever to
run quick/smoke fstests against EROFS? (I assume this could be
reproduced via fstests..?).

> v1: https://lore.kernel.org/r/20250319025953.3559299-1-hsiangkao@xxxxxxxxxxxxxxxxx
> change since v1:
>  - iomap_iter_advance() directly instead of `goto done`
>    as suggested by Christoph.
> 
>  fs/iomap/buffered-io.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index d52cfdc299c4..814b7f679486 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -372,9 +372,14 @@ static int iomap_readpage_iter(struct iomap_iter *iter,
>  	struct iomap_folio_state *ifs;
>  	size_t poff, plen;
>  	sector_t sector;
> +	int ret;
>  
> -	if (iomap->type == IOMAP_INLINE)
> -		return iomap_read_inline_data(iter, folio);
> +	if (iomap->type == IOMAP_INLINE) {
> +		ret = iomap_read_inline_data(iter, folio);
> +		if (ret)
> +			return ret;
> +		return iomap_iter_advance(iter, &length);
> +	}

Technically you could use iomap_iter_advance_full() here, but since
length is already defined for other purposes it doesn't really make much
difference. LGTM:

Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>

>  
>  	/* zero post-eof blocks as the page may be mapped */
>  	ifs = ifs_alloc(iter->inode, folio, iter->flags);
> -- 
> 2.43.5
> 





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux