[PATCH 1/2] iomap: don't bother unsharing delalloc extents

[PATCH 1/2] iomap: don't bother unsharing delalloc extents

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

If unshare encounters a delalloc reservation in the srcmap, that means
that the file range isn't shared because delalloc reservations cannot be
reflinked.  Therefore, don't try to unshare them.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 fs/iomap/buffered-io.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 11ea747228aee..c1c559e0cc07c 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1321,7 +1321,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
 		return length;
 
 	/*
-	 * Don't bother with holes or unwritten extents.
+	 * Don't bother with delalloc reservations, holes or unwritten extents.
 	 *
 	 * Note that we use srcmap directly instead of iomap_iter_srcmap as
 	 * unsharing requires providing a separate source map, and the presence
@@ -1330,6 +1330,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
 	 * fork for XFS.
 	 */
 	if (iter->srcmap.type == IOMAP_HOLE ||
+	    iter->srcmap.type == IOMAP_DELALLOC ||
 	    iter->srcmap.type == IOMAP_UNWRITTEN)
 		return length;
 

[PATCH 2/2] iomap: constrain the file range passed to iomap_file_unshare

[Darrick J. Wong]

From: Darrick J. Wong <djwong@kernel.org>

File contents can only be shared (i.e. reflinked) below EOF, so it makes
no sense to try to unshare ranges beyond EOF.  Constrain the file range
parameters here so that we don't have to do that in the callers.

Fixes: 5f4e5752a8a3 ("fs: add iomap_file_dirty")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 fs/dax.c               |    6 +++++-
 fs/iomap/buffered-io.c |    6 +++++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index becb4a6920c6a..c62acd2812f8d 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1305,11 +1305,15 @@ int dax_file_unshare(struct inode *inode, loff_t pos, loff_t len,
 	struct iomap_iter iter = {
 		.inode		= inode,
 		.pos		= pos,
-		.len		= len,
 		.flags		= IOMAP_WRITE | IOMAP_UNSHARE | IOMAP_DAX,
 	};
+	loff_t size = i_size_read(inode);
 	int ret;
 
+	if (pos < 0 || pos >= size)
+		return 0;
+
+	iter.len = min(len, size - pos);
 	while ((ret = iomap_iter(&iter, ops)) > 0)
 		iter.processed = dax_unshare_iter(&iter);
 	return ret;
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index c1c559e0cc07c..78ebd265f4259 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1375,11 +1375,15 @@ iomap_file_unshare(struct inode *inode, loff_t pos, loff_t len,
 	struct iomap_iter iter = {
 		.inode		= inode,
 		.pos		= pos,
-		.len		= len,
 		.flags		= IOMAP_WRITE | IOMAP_UNSHARE,
 	};
+	loff_t size = i_size_read(inode);
 	int ret;
 
+	if (pos < 0 || pos >= size)
+		return 0;
+
+	iter.len = min(len, size - pos);
 	while ((ret = iomap_iter(&iter, ops)) > 0)
 		iter.processed = iomap_unshare_iter(&iter);
 	return ret;

Re: [PATCH 2/2] iomap: constrain the file range passed to iomap_file_unshare

[Christoph Hellwig]

On Wed, Oct 02, 2024 at 08:02:13AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> File contents can only be shared (i.e. reflinked) below EOF, so it makes
> no sense to try to unshare ranges beyond EOF.  Constrain the file range
> parameters here so that we don't have to do that in the callers.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 2/2] iomap: constrain the file range passed to iomap_file_unshare

[Brian Foster]

On Wed, Oct 02, 2024 at 08:02:13AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> File contents can only be shared (i.e. reflinked) below EOF, so it makes
> no sense to try to unshare ranges beyond EOF.  Constrain the file range
> parameters here so that we don't have to do that in the callers.
> 
> Fixes: 5f4e5752a8a3 ("fs: add iomap_file_dirty")
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/dax.c               |    6 +++++-
>  fs/iomap/buffered-io.c |    6 +++++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index becb4a6920c6a..c62acd2812f8d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1305,11 +1305,15 @@ int dax_file_unshare(struct inode *inode, loff_t pos, loff_t len,
>  	struct iomap_iter iter = {
>  		.inode		= inode,
>  		.pos		= pos,
> -		.len		= len,
>  		.flags		= IOMAP_WRITE | IOMAP_UNSHARE | IOMAP_DAX,
>  	};
> +	loff_t size = i_size_read(inode);
>  	int ret;
>  
> +	if (pos < 0 || pos >= size)
> +		return 0;
> +
> +	iter.len = min(len, size - pos);
>  	while ((ret = iomap_iter(&iter, ops)) > 0)
>  		iter.processed = dax_unshare_iter(&iter);
>  	return ret;
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index c1c559e0cc07c..78ebd265f4259 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1375,11 +1375,15 @@ iomap_file_unshare(struct inode *inode, loff_t pos, loff_t len,
>  	struct iomap_iter iter = {
>  		.inode		= inode,
>  		.pos		= pos,
> -		.len		= len,
>  		.flags		= IOMAP_WRITE | IOMAP_UNSHARE,
>  	};
> +	loff_t size = i_size_read(inode);
>  	int ret;
>  
> +	if (pos < 0 || pos >= size)
> +		return 0;
> +
> +	iter.len = min(len, size - pos);
>  	while ((ret = iomap_iter(&iter, ops)) > 0)
>  		iter.processed = iomap_unshare_iter(&iter);
>  	return ret;
> 

Heh. This was pretty much my local fix when I was testing fsx unshare
range, so LGTM. Apologies, I probably should have just sent it out. It
just seemed like Julian was 90% there, but then review went off the
rails and I guess I lost interest. Anyways, thanks for the fix:

Reviewed-by: Brian Foster <bfoster@redhat.com>

Re: [PATCH 2/2] iomap: constrain the file range passed to iomap_file_unshare

[Julian Sun]

On Wed, 2024-10-02 at 08:02 -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> File contents can only be shared (i.e. reflinked) below EOF, so it makes
> no sense to try to unshare ranges beyond EOF.  Constrain the file range
> parameters here so that we don't have to do that in the callers.
> 
> Fixes: 5f4e5752a8a3 ("fs: add iomap_file_dirty")
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/dax.c               |    6 +++++-
>  fs/iomap/buffered-io.c |    6 +++++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index becb4a6920c6a..c62acd2812f8d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1305,11 +1305,15 @@ int dax_file_unshare(struct inode *inode, loff_t
> pos, loff_t len,
>         struct iomap_iter iter = {
>                 .inode          = inode,
>                 .pos            = pos,
> -               .len            = len,
>                 .flags          = IOMAP_WRITE | IOMAP_UNSHARE |
> IOMAP_DAX,
>         };
> +       loff_t size = i_size_read(inode);
>         int ret;
>  
> +       if (pos < 0 || pos >= size)
> +               return 0;
> +
> +       iter.len = min(len, size - pos);
>         while ((ret = iomap_iter(&iter, ops)) > 0)
>                 iter.processed = dax_unshare_iter(&iter);
>         return ret;
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index c1c559e0cc07c..78ebd265f4259 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1375,11 +1375,15 @@ iomap_file_unshare(struct inode *inode, loff_t
> pos, loff_t len,
>         struct iomap_iter iter = {
>                 .inode          = inode,
>                 .pos            = pos,
> -               .len            = len,
>                 .flags          = IOMAP_WRITE | IOMAP_UNSHARE,
>         };
> +       loff_t size = i_size_read(inode);
>         int ret;
>  
> +       if (pos < 0 || pos >= size)
> +               return 0;
> +
> +       iter.len = min(len, size - pos);
>         while ((ret = iomap_iter(&iter, ops)) > 0)
>                 iter.processed = iomap_unshare_iter(&iter);
>         return ret;

Sorry I didn’t update the patch sooner—I was planning to get to it after
wrapping up my week-long vacation... Anyway, thanks for the patch, it looks
great!

Thanks,
-- 
Julian Sun <sunjunchao2870@gmail.com>

Re: [PATCH 1/2] iomap: don't bother unsharing delalloc extents

[Christoph Hellwig]

On Wed, Oct 02, 2024 at 08:00:40AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> If unshare encounters a delalloc reservation in the srcmap, that means
> that the file range isn't shared because delalloc reservations cannot be
> reflinked.  Therefore, don't try to unshare them.

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

Re: [PATCH 1/2] iomap: don't bother unsharing delalloc extents

[Brian Foster]

On Wed, Oct 02, 2024 at 08:00:40AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> If unshare encounters a delalloc reservation in the srcmap, that means
> that the file range isn't shared because delalloc reservations cannot be
> reflinked.  Therefore, don't try to unshare them.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/iomap/buffered-io.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 11ea747228aee..c1c559e0cc07c 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1321,7 +1321,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
>  		return length;
>  
>  	/*
> -	 * Don't bother with holes or unwritten extents.
> +	 * Don't bother with delalloc reservations, holes or unwritten extents.
>  	 *
>  	 * Note that we use srcmap directly instead of iomap_iter_srcmap as
>  	 * unsharing requires providing a separate source map, and the presence
> @@ -1330,6 +1330,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
>  	 * fork for XFS.
>  	 */
>  	if (iter->srcmap.type == IOMAP_HOLE ||
> +	    iter->srcmap.type == IOMAP_DELALLOC ||
>  	    iter->srcmap.type == IOMAP_UNWRITTEN)
>  		return length;
>  
> 

IIUC in the case of shared blocks srcmap always refers to the data fork
(so delalloc in the COW fork is not an issue). If so:

Reviewed-by: Brian Foster <bfoster@redhat.com>

Re: [PATCH 1/2] iomap: don't bother unsharing delalloc extents

[Darrick J. Wong]

On Wed, Oct 02, 2024 at 12:01:06PM -0400, Brian Foster wrote:
> On Wed, Oct 02, 2024 at 08:00:40AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > If unshare encounters a delalloc reservation in the srcmap, that means
> > that the file range isn't shared because delalloc reservations cannot be
> > reflinked.  Therefore, don't try to unshare them.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  fs/iomap/buffered-io.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index 11ea747228aee..c1c559e0cc07c 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -1321,7 +1321,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
> >  		return length;
> >  
> >  	/*
> > -	 * Don't bother with holes or unwritten extents.
> > +	 * Don't bother with delalloc reservations, holes or unwritten extents.
> >  	 *
> >  	 * Note that we use srcmap directly instead of iomap_iter_srcmap as
> >  	 * unsharing requires providing a separate source map, and the presence
> > @@ -1330,6 +1330,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
> >  	 * fork for XFS.
> >  	 */
> >  	if (iter->srcmap.type == IOMAP_HOLE ||
> > +	    iter->srcmap.type == IOMAP_DELALLOC ||
> >  	    iter->srcmap.type == IOMAP_UNWRITTEN)
> >  		return length;
> >  
> > 
> 
> IIUC in the case of shared blocks srcmap always refers to the data fork
> (so delalloc in the COW fork is not an issue). If so:

Yep.

> Reviewed-by: Brian Foster <bfoster@redhat.com>

Thanks!

--D

Re: [PATCH 1/2] iomap: don't bother unsharing delalloc extents

[Christian Brauner]

On Wed, 02 Oct 2024 08:00:40 -0700, Darrick J. Wong wrote:
> If unshare encounters a delalloc reservation in the srcmap, that means
> that the file range isn't shared because delalloc reservations cannot be
> reflinked.  Therefore, don't try to unshare them.
> 
> 

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/2] iomap: don't bother unsharing delalloc extents
      https://git.kernel.org/vfs/vfs/c/f7a4874d977b
[2/2] iomap: constrain the file range passed to iomap_file_unshare
      https://git.kernel.org/vfs/vfs/c/a311a08a4237