linux-next: manual merge of the vfs tree with the erofs tree

linux-next: manual merge of the vfs tree with the erofs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

Hi all,

Today's linux-next merge of the vfs tree got a conflict in:

  fs/erofs/super.c

between commit:

  e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")

from the erofs tree and commit:

  91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")

from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/erofs/super.c
index 8e46d204a0c2,2c0bad903fa6..000000000000
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
  	sb->s_time_gran = 1;
  
  	sb->s_op = &erofs_sops;
 -
 -#ifdef CONFIG_EROFS_FS_XATTR
  	sb->s_xattr = erofs_xattr_handlers;
 -#endif
  
- 	/* set erofs default mount options */
- 	erofs_default_options(sbi);
- 
- 	err = erofs_parse_options(sb, data);
- 	if (err)
- 		return err;
- 
- 	if (test_opt(sbi, POSIX_ACL))
+ 	if (test_opt(ctx, POSIX_ACL))
  		sb->s_flags |= SB_POSIXACL;
  	else
  		sb->s_flags &= ~SB_POSIXACL;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Al Viro]

On Fri, May 29, 2020 at 11:45:01AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/erofs/super.c
> 
> between commit:
> 
>   e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")
> 
> from the erofs tree and commit:
> 
>   91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")
> 
> from the vfs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/erofs/super.c
> index 8e46d204a0c2,2c0bad903fa6..000000000000
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
>   	sb->s_time_gran = 1;
>   
>   	sb->s_op = &erofs_sops;
>  -
>  -#ifdef CONFIG_EROFS_FS_XATTR
>   	sb->s_xattr = erofs_xattr_handlers;
>  -#endif
>   
> - 	/* set erofs default mount options */
> - 	erofs_default_options(sbi);
> - 
> - 	err = erofs_parse_options(sb, data);
> - 	if (err)
> - 		return err;
> - 
> - 	if (test_opt(sbi, POSIX_ACL))
> + 	if (test_opt(ctx, POSIX_ACL))
>   		sb->s_flags |= SB_POSIXACL;
>   	else
>   		sb->s_flags &= ~SB_POSIXACL;

FWIW, I would be glad to have that old erofs commit moved over to
erofs tree...  Folks?

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Gao Xiang]

Hi Al,

On Fri, May 29, 2020 at 02:51:11AM +0100, Al Viro wrote:
> On Fri, May 29, 2020 at 11:45:01AM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the vfs tree got a conflict in:
> > 
> >   fs/erofs/super.c
> > 
> > between commit:
> > 
> >   e7cda1ee94f4 ("erofs: code cleanup by removing ifdef macro surrounding")
> > 
> > from the erofs tree and commit:
> > 
> >   91a7c5e1d30e ("erofs: convert to use the new mount fs_context api")
> > 
> > from the vfs tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc fs/erofs/super.c
> > index 8e46d204a0c2,2c0bad903fa6..000000000000
> > --- a/fs/erofs/super.c
> > +++ b/fs/erofs/super.c
> > @@@ -408,16 -365,12 +365,9 @@@ static int erofs_fc_fill_super(struct s
> >   	sb->s_time_gran = 1;
> >   
> >   	sb->s_op = &erofs_sops;
> >  -
> >  -#ifdef CONFIG_EROFS_FS_XATTR
> >   	sb->s_xattr = erofs_xattr_handlers;
> >  -#endif
> >   
> > - 	/* set erofs default mount options */
> > - 	erofs_default_options(sbi);
> > - 
> > - 	err = erofs_parse_options(sb, data);
> > - 	if (err)
> > - 		return err;
> > - 
> > - 	if (test_opt(sbi, POSIX_ACL))
> > + 	if (test_opt(ctx, POSIX_ACL))
> >   		sb->s_flags |= SB_POSIXACL;
> >   	else
> >   		sb->s_flags &= ~SB_POSIXACL;
> 
> FWIW, I would be glad to have that old erofs commit moved over to
> erofs tree...  Folks?

I'm fine with that, although I think it's mainly with vfs changes
so could be better though with vfs tree. I will add this patch
tomorrow anyway... Thanks for reminder!

Thanks,
Gao Xiang

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Al Viro]

On Fri, May 29, 2020 at 11:40:07AM +0800, Gao Xiang wrote:

> I'm fine with that, although I think it's mainly with vfs changes
> so could be better though with vfs tree. I will add this patch
> tomorrow anyway... Thanks for reminder!

FWIW, my reasoning here is
	* erofs tree exists and
	* the patch is erofs-specific, affects nothing outside and
has no dependencies with anything currently done in VFS or in other
filesystems and
	* it does have (trivial) conflicts with the stuff in
erofs tree

So putting it into erofs tree would seem to be an obvious approach -
minimizes the amount of cross-tree dependencies and headache for
everyone involved...

I'm dropping it from #work.misc and #for-next now.

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Gao Xiang]

On Fri, May 29, 2020 at 03:36:13PM +0100, Al Viro wrote:
> On Fri, May 29, 2020 at 11:40:07AM +0800, Gao Xiang wrote:
> 
> > I'm fine with that, although I think it's mainly with vfs changes
> > so could be better though with vfs tree. I will add this patch
> > tomorrow anyway... Thanks for reminder!
> 
> FWIW, my reasoning here is
> 	* erofs tree exists and
> 	* the patch is erofs-specific, affects nothing outside and
> has no dependencies with anything currently done in VFS or in other
> filesystems and
> 	* it does have (trivial) conflicts with the stuff in
> erofs tree
> 
> So putting it into erofs tree would seem to be an obvious approach -
> minimizes the amount of cross-tree dependencies and headache for
> everyone involved...

That is reasonable. btw, our initial thought was that relates to new
mount apis and we weren't very confident if it really went the
filesystem itself...

> 
> I'm dropping it from #work.misc and #for-next now.

I will push out for next cycle. Thanks for detailed explanation.

Thanks,
Gao Xiang

> 

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Gao Xiang]

On Mon, Dec 05, 2022 at 03:11:07PM +1100, Stephen Rothwell wrote:
> Hi Gao,
> 
> On Mon, 5 Dec 2022 11:13:50 +0800 Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >
> > On Mon, Dec 05, 2022 at 09:24:15AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the vfs tree got a conflict in:
> > > 
> > >   fs/erofs/fscache.c
> > > 
> > > between commits:
> > > 
> > >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> > >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> > > 
> > > from the erofs tree and commit:
> > > 
> > >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> > > 
> > > from the vfs tree.  
> > 
> > Is the commit from the vfs tree correct?
> > 
> > The conflict fix looks good to me (we tend to enable large folios in the
> > next cycle.)
> 
> The commits should be
> 
>   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
>   a21274e993a6 ("erofs: support large folios for fscache mode")
> 
> from the erofs tree and
> 
>   de4eda9de2d9 ("use less confusing names for iov_iter direction initializers")
> 
> from the vfs tree.
> 
> Cut and paste weirdness caught me again :-(

Thanks for the confirmation!

Thanks,
Gao Xiang

> 
> -- 
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi Gao,

On Mon, 5 Dec 2022 11:13:50 +0800 Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> On Mon, Dec 05, 2022 at 09:24:15AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the vfs tree got a conflict in:
> > 
> >   fs/erofs/fscache.c
> > 
> > between commits:
> > 
> >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> > 
> > from the erofs tree and commit:
> > 
> >   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> > 
> > from the vfs tree.  
> 
> Is the commit from the vfs tree correct?
> 
> The conflict fix looks good to me (we tend to enable large folios in the
> next cycle.)

The commits should be

  89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
  a21274e993a6 ("erofs: support large folios for fscache mode")

from the erofs tree and

  de4eda9de2d9 ("use less confusing names for iov_iter direction initializers")

from the vfs tree.

Cut and paste weirdness caught me again :-(

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Gao Xiang]

Hi Stephen,

On Mon, Dec 05, 2022 at 09:24:15AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/erofs/fscache.c
> 
> between commits:
> 
>   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
>   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> 
> from the erofs tree and commit:
> 
>   89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
> 
> from the vfs tree.

Is the commit from the vfs tree correct?

The conflict fix looks good to me (we tend to enable large folios in the
next cycle.)

Thanks,
Gao Xiang

> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/erofs/fscache.c
> index f14886c479bd,4c837be3b6e3..000000000000
> --- a/fs/erofs/fscache.c
> +++ b/fs/erofs/fscache.c
> @@@ -126,28 -159,47 +126,28 @@@ static int erofs_fscache_read_folios_as
>   
>   	ret = fscache_begin_read_operation(cres, cookie);
>   	if (ret)
>  -		goto out;
>  +		return ret;
>   
>   	while (done < len) {
>  -		subreq = kzalloc(sizeof(struct netfs_io_subrequest),
>  -				 GFP_KERNEL);
>  -		if (subreq) {
>  -			INIT_LIST_HEAD(&subreq->rreq_link);
>  -			refcount_set(&subreq->ref, 2);
>  -			subreq->rreq = rreq;
>  -			refcount_inc(&rreq->ref);
>  -		} else {
>  -			ret = -ENOMEM;
>  -			goto out;
>  -		}
>  -
>  -		subreq->start = pstart + done;
>  -		subreq->len	=  len - done;
>  -		subreq->flags = 1 << NETFS_SREQ_ONDEMAND;
>  +		loff_t sstart = pstart + done;
>  +		size_t slen = len - done;
>  +		unsigned long flags = 1 << NETFS_SREQ_ONDEMAND;
>   
>  -		list_add_tail(&subreq->rreq_link, &rreq->subrequests);
>  -
>  -		source = cres->ops->prepare_read(subreq, LLONG_MAX);
>  -		if (WARN_ON(subreq->len == 0))
>  +		source = cres->ops->prepare_ondemand_read(cres,
>  +				sstart, &slen, LLONG_MAX, &flags, 0);
>  +		if (WARN_ON(slen == 0))
>   			source = NETFS_INVALID_READ;
>   		if (source != NETFS_READ_FROM_CACHE) {
>  -			erofs_err(sb, "failed to fscache prepare_read (source %d)",
>  -				  source);
>  -			ret = -EIO;
>  -			subreq->error = ret;
>  -			erofs_fscache_put_subrequest(subreq);
>  -			goto out;
>  +			erofs_err(sb, "failed to fscache prepare_read (source %d)", source);
>  +			return -EIO;
>   		}
>   
>  -		atomic_inc(&rreq->nr_outstanding);
>  +		refcount_inc(&req->ref);
> - 		iov_iter_xarray(&iter, READ, &req->mapping->i_pages,
> ++		iov_iter_xarray(&iter, ITER_DEST, &req->mapping->i_pages,
>  +				lstart + done, slen);
>   
>  -		iov_iter_xarray(&iter, ITER_DEST, &rreq->mapping->i_pages,
>  -				start + done, subreq->len);
>  -
>  -		ret = fscache_read(cres, subreq->start, &iter,
>  -				   NETFS_READ_HOLE_FAIL,
>  -				   erofc_fscache_subreq_complete, subreq);
>  +		ret = fscache_read(cres, sstart, &iter, NETFS_READ_HOLE_FAIL,
>  +				   erofs_fscache_subreq_complete, req);
>   		if (ret == -EIOCBQUEUED)
>   			ret = 0;
>   		if (ret) {
> @@@ -233,19 -297,17 +233,19 @@@ static int erofs_fscache_data_read_slic
>   		}
>   		iov_iter_zero(PAGE_SIZE - size, &iter);
>   		erofs_put_metabuf(&buf);
>  -		return PAGE_SIZE;
>  +		primary->submitted += PAGE_SIZE;
>  +		return 0;
>   	}
>   
>  +	count = primary->len - primary->submitted;
>   	if (!(map.m_flags & EROFS_MAP_MAPPED)) {
> - 		iov_iter_xarray(&iter, READ, &mapping->i_pages, pos, count);
>  -		count = len;
> + 		iov_iter_xarray(&iter, ITER_DEST, &mapping->i_pages, pos, count);
>   		iov_iter_zero(count, &iter);
>  -		return count;
>  +		primary->submitted += count;
>  +		return 0;
>   	}
>   
>  -	count = min_t(size_t, map.m_llen - (pos - map.m_la), len);
>  +	count = min_t(size_t, map.m_llen - (pos - map.m_la), count);
>   	DBG_BUGON(!count || count % PAGE_SIZE);
>   
>   	mdev = (struct erofs_map_dev) {

linux-next: manual merge of the vfs tree with the erofs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

Hi all,

Today's linux-next merge of the vfs tree got a conflict in:

  fs/erofs/fscache.c

between commits:

  89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")
  89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")

from the erofs tree and commit:

  89175ef1262d ("erofs: switch to prepare_ondemand_read() in fscache mode")

from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/erofs/fscache.c
index f14886c479bd,4c837be3b6e3..000000000000
--- a/fs/erofs/fscache.c
+++ b/fs/erofs/fscache.c
@@@ -126,28 -159,47 +126,28 @@@ static int erofs_fscache_read_folios_as
  
  	ret = fscache_begin_read_operation(cres, cookie);
  	if (ret)
 -		goto out;
 +		return ret;
  
  	while (done < len) {
 -		subreq = kzalloc(sizeof(struct netfs_io_subrequest),
 -				 GFP_KERNEL);
 -		if (subreq) {
 -			INIT_LIST_HEAD(&subreq->rreq_link);
 -			refcount_set(&subreq->ref, 2);
 -			subreq->rreq = rreq;
 -			refcount_inc(&rreq->ref);
 -		} else {
 -			ret = -ENOMEM;
 -			goto out;
 -		}
 -
 -		subreq->start = pstart + done;
 -		subreq->len	=  len - done;
 -		subreq->flags = 1 << NETFS_SREQ_ONDEMAND;
 +		loff_t sstart = pstart + done;
 +		size_t slen = len - done;
 +		unsigned long flags = 1 << NETFS_SREQ_ONDEMAND;
  
 -		list_add_tail(&subreq->rreq_link, &rreq->subrequests);
 -
 -		source = cres->ops->prepare_read(subreq, LLONG_MAX);
 -		if (WARN_ON(subreq->len == 0))
 +		source = cres->ops->prepare_ondemand_read(cres,
 +				sstart, &slen, LLONG_MAX, &flags, 0);
 +		if (WARN_ON(slen == 0))
  			source = NETFS_INVALID_READ;
  		if (source != NETFS_READ_FROM_CACHE) {
 -			erofs_err(sb, "failed to fscache prepare_read (source %d)",
 -				  source);
 -			ret = -EIO;
 -			subreq->error = ret;
 -			erofs_fscache_put_subrequest(subreq);
 -			goto out;
 +			erofs_err(sb, "failed to fscache prepare_read (source %d)", source);
 +			return -EIO;
  		}
  
 -		atomic_inc(&rreq->nr_outstanding);
 +		refcount_inc(&req->ref);
- 		iov_iter_xarray(&iter, READ, &req->mapping->i_pages,
++		iov_iter_xarray(&iter, ITER_DEST, &req->mapping->i_pages,
 +				lstart + done, slen);
  
 -		iov_iter_xarray(&iter, ITER_DEST, &rreq->mapping->i_pages,
 -				start + done, subreq->len);
 -
 -		ret = fscache_read(cres, subreq->start, &iter,
 -				   NETFS_READ_HOLE_FAIL,
 -				   erofc_fscache_subreq_complete, subreq);
 +		ret = fscache_read(cres, sstart, &iter, NETFS_READ_HOLE_FAIL,
 +				   erofs_fscache_subreq_complete, req);
  		if (ret == -EIOCBQUEUED)
  			ret = 0;
  		if (ret) {
@@@ -233,19 -297,17 +233,19 @@@ static int erofs_fscache_data_read_slic
  		}
  		iov_iter_zero(PAGE_SIZE - size, &iter);
  		erofs_put_metabuf(&buf);
 -		return PAGE_SIZE;
 +		primary->submitted += PAGE_SIZE;
 +		return 0;
  	}
  
 +	count = primary->len - primary->submitted;
  	if (!(map.m_flags & EROFS_MAP_MAPPED)) {
- 		iov_iter_xarray(&iter, READ, &mapping->i_pages, pos, count);
 -		count = len;
+ 		iov_iter_xarray(&iter, ITER_DEST, &mapping->i_pages, pos, count);
  		iov_iter_zero(count, &iter);
 -		return count;
 +		primary->submitted += count;
 +		return 0;
  	}
  
 -	count = min_t(size_t, map.m_llen - (pos - map.m_la), len);
 +	count = min_t(size_t, map.m_llen - (pos - map.m_la), count);
  	DBG_BUGON(!count || count % PAGE_SIZE);
  
  	mdev = (struct erofs_map_dev) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the vfs tree with the erofs tree

[Jingbo Xu]

On 11/28/22 6:13 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs tree got a conflict in:
> 
>   fs/erofs/fscache.c
> 
> between commit:
> 
>   313e9413d512 ("erofs: switch to prepare_ondemand_read() in fscache mode")
> 
> from the erofs tree and commit:
> 
>   de4eda9de2d9 ("use less confusing names for iov_iter direction initializers")
> 
> from the vfs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

It looks good to me.  Thanks.


-- 
Thanks,
Jingbo

linux-next: manual merge of the vfs tree with the erofs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

Hi all,

Today's linux-next merge of the vfs tree got a conflict in:

  fs/erofs/fscache.c

between commit:

  313e9413d512 ("erofs: switch to prepare_ondemand_read() in fscache mode")

from the erofs tree and commit:

  de4eda9de2d9 ("use less confusing names for iov_iter direction initializers")

from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/erofs/fscache.c
index 3e794891cd91,4c837be3b6e3..000000000000
--- a/fs/erofs/fscache.c
+++ b/fs/erofs/fscache.c
@@@ -99,28 -159,47 +99,28 @@@ static int erofs_fscache_read_folios_as
  
  	ret = fscache_begin_read_operation(cres, cookie);
  	if (ret)
 -		goto out;
 +		return ret;
  
  	while (done < len) {
 -		subreq = kzalloc(sizeof(struct netfs_io_subrequest),
 -				 GFP_KERNEL);
 -		if (subreq) {
 -			INIT_LIST_HEAD(&subreq->rreq_link);
 -			refcount_set(&subreq->ref, 2);
 -			subreq->rreq = rreq;
 -			refcount_inc(&rreq->ref);
 -		} else {
 -			ret = -ENOMEM;
 -			goto out;
 -		}
 -
 -		subreq->start = pstart + done;
 -		subreq->len	=  len - done;
 -		subreq->flags = 1 << NETFS_SREQ_ONDEMAND;
 +		loff_t sstart = pstart + done;
 +		size_t slen = len - done;
 +		unsigned long flags = 1 << NETFS_SREQ_ONDEMAND;
  
 -		list_add_tail(&subreq->rreq_link, &rreq->subrequests);
 -
 -		source = cres->ops->prepare_read(subreq, LLONG_MAX);
 -		if (WARN_ON(subreq->len == 0))
 +		source = cres->ops->prepare_ondemand_read(cres,
 +				sstart, &slen, LLONG_MAX, &flags, 0);
 +		if (WARN_ON(slen == 0))
  			source = NETFS_INVALID_READ;
  		if (source != NETFS_READ_FROM_CACHE) {
 -			erofs_err(sb, "failed to fscache prepare_read (source %d)",
 -				  source);
 -			ret = -EIO;
 -			subreq->error = ret;
 -			erofs_fscache_put_subrequest(subreq);
 -			goto out;
 +			erofs_err(sb, "failed to fscache prepare_read (source %d)", source);
 +			return -EIO;
  		}
  
 -		atomic_inc(&rreq->nr_outstanding);
 +		refcount_inc(&req->ref);
- 		iov_iter_xarray(&iter, READ, &req->mapping->i_pages,
++		iov_iter_xarray(&iter, ITER_DEST, &req->mapping->i_pages,
 +				lstart + done, slen);
  
 -		iov_iter_xarray(&iter, ITER_DEST, &rreq->mapping->i_pages,
 -				start + done, subreq->len);
 -
 -		ret = fscache_read(cres, subreq->start, &iter,
 -				   NETFS_READ_HOLE_FAIL,
 -				   erofc_fscache_subreq_complete, subreq);
 +		ret = fscache_read(cres, sstart, &iter, NETFS_READ_HOLE_FAIL,
 +				   erofs_fscache_subreq_complete, req);
  		if (ret == -EIOCBQUEUED)
  			ret = 0;
  		if (ret) {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]