| Message ID | 20221128160813.3950889-1-bfoster@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fs/remap_range: avoid spurious writeback on zero length request | expand |
On Mon, Nov 28, 2022 at 11:08:13AM -0500, Brian Foster wrote: > generic_remap_checks() can reduce the effective request length (i.e., > after the reflink extend to EOF case is handled) down to zero. If this > occurs, __generic_remap_file_range_prep() proceeds through dio > serialization, file mapping flush calls, and may invoke file_modified() > before returning back to the filesystem caller, all of which immediately > check for len == 0 and return. > > While this is mostly harmless, it is spurious and not completely > without side effect. A filemap write call can submit I/O (but not > wait on it) when the specified end byte precedes the start but > happens to land on the same aligned page boundary, which can occur > from __generic_remap_file_range_prep() when len is 0. > > The dedupe path already has a len == 0 check to break out before doing > range comparisons. Lift this check a bit earlier in the function to > cover the general case of len == 0 and avoid the unnecessary work. > > Signed-off-by: Brian Foster <bfoster@redhat.com> Looks correct, Reviewed-by: Darrick J. Wong <djwong@kernel.org> Should there be an(other) "if (!*len) return 0;" after the generic_remap_check_len call to skip the mtime update if the remap request gets shortened to avoid remapping an unaligned eofblock into the middle of the destination file? --D > --- > fs/remap_range.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/fs/remap_range.c b/fs/remap_range.c > index 654912d06862..32ea992f9acc 100644 > --- a/fs/remap_range.c > +++ b/fs/remap_range.c > @@ -306,6 +306,8 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, > remap_flags); > if (ret) > return ret; > + if (*len == 0) > + return 0; > > /* Wait for the completion of any pending IOs on both files */ > inode_dio_wait(inode_in); > @@ -328,9 +330,6 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, > if (remap_flags & REMAP_FILE_DEDUP) { > bool is_same = false; > > - if (*len == 0) > - return 0; > - > if (!IS_DAX(inode_in)) > ret = vfs_dedupe_file_range_compare(file_in, pos_in, > file_out, pos_out, *len, &is_same); > -- > 2.37.3 >
On Mon, Nov 28, 2022 at 09:22:53AM -0800, Darrick J. Wong wrote: > On Mon, Nov 28, 2022 at 11:08:13AM -0500, Brian Foster wrote: > > generic_remap_checks() can reduce the effective request length (i.e., > > after the reflink extend to EOF case is handled) down to zero. If this > > occurs, __generic_remap_file_range_prep() proceeds through dio > > serialization, file mapping flush calls, and may invoke file_modified() > > before returning back to the filesystem caller, all of which immediately > > check for len == 0 and return. > > > > While this is mostly harmless, it is spurious and not completely > > without side effect. A filemap write call can submit I/O (but not > > wait on it) when the specified end byte precedes the start but > > happens to land on the same aligned page boundary, which can occur > > from __generic_remap_file_range_prep() when len is 0. > > > > The dedupe path already has a len == 0 check to break out before doing > > range comparisons. Lift this check a bit earlier in the function to > > cover the general case of len == 0 and avoid the unnecessary work. > > > > Signed-off-by: Brian Foster <bfoster@redhat.com> > > Looks correct, > Reviewed-by: Darrick J. Wong <djwong@kernel.org> > > Should there be an(other) "if (!*len) return 0;" after the > generic_remap_check_len call to skip the mtime update if the remap > request gets shortened to avoid remapping an unaligned eofblock into the > middle of the destination file? > Looks sensible to me, though I guess I would do something like the appended diff. Do you want to just fold that into this patch? Brian --- 8< --- diff --git a/fs/remap_range.c b/fs/remap_range.c index 32ea992f9acc..2f236c9c5802 100644 --- a/fs/remap_range.c +++ b/fs/remap_range.c @@ -347,7 +347,7 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, ret = generic_remap_check_len(inode_in, inode_out, pos_out, len, remap_flags); - if (ret) + if (ret || *len == 0) return ret; /* If can't alter the file contents, we're done. */
On Tue, Nov 29, 2022 at 06:29:51AM -0500, Brian Foster wrote: > On Mon, Nov 28, 2022 at 09:22:53AM -0800, Darrick J. Wong wrote: > > On Mon, Nov 28, 2022 at 11:08:13AM -0500, Brian Foster wrote: > > > generic_remap_checks() can reduce the effective request length (i.e., > > > after the reflink extend to EOF case is handled) down to zero. If this > > > occurs, __generic_remap_file_range_prep() proceeds through dio > > > serialization, file mapping flush calls, and may invoke file_modified() > > > before returning back to the filesystem caller, all of which immediately > > > check for len == 0 and return. > > > > > > While this is mostly harmless, it is spurious and not completely > > > without side effect. A filemap write call can submit I/O (but not > > > wait on it) when the specified end byte precedes the start but > > > happens to land on the same aligned page boundary, which can occur > > > from __generic_remap_file_range_prep() when len is 0. > > > > > > The dedupe path already has a len == 0 check to break out before doing > > > range comparisons. Lift this check a bit earlier in the function to > > > cover the general case of len == 0 and avoid the unnecessary work. > > > > > > Signed-off-by: Brian Foster <bfoster@redhat.com> > > > > Looks correct, > > Reviewed-by: Darrick J. Wong <djwong@kernel.org> > > > > Should there be an(other) "if (!*len) return 0;" after the > > generic_remap_check_len call to skip the mtime update if the remap > > request gets shortened to avoid remapping an unaligned eofblock into the > > middle of the destination file? > > > > Looks sensible to me, though I guess I would do something like the > appended diff. Do you want to just fold that into this patch? Yes, could you fold it in and send a v2 with my rvb on it, please? --D > Brian > > --- 8< --- > > diff --git a/fs/remap_range.c b/fs/remap_range.c > index 32ea992f9acc..2f236c9c5802 100644 > --- a/fs/remap_range.c > +++ b/fs/remap_range.c > @@ -347,7 +347,7 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, > > ret = generic_remap_check_len(inode_in, inode_out, pos_out, len, > remap_flags); > - if (ret) > + if (ret || *len == 0) > return ret; > > /* If can't alter the file contents, we're done. */ >
On Tue, Nov 29, 2022 at 10:18:53AM -0800, Darrick J. Wong wrote: > On Tue, Nov 29, 2022 at 06:29:51AM -0500, Brian Foster wrote: > > On Mon, Nov 28, 2022 at 09:22:53AM -0800, Darrick J. Wong wrote: > > > On Mon, Nov 28, 2022 at 11:08:13AM -0500, Brian Foster wrote: > > > > generic_remap_checks() can reduce the effective request length (i.e., > > > > after the reflink extend to EOF case is handled) down to zero. If this > > > > occurs, __generic_remap_file_range_prep() proceeds through dio > > > > serialization, file mapping flush calls, and may invoke file_modified() > > > > before returning back to the filesystem caller, all of which immediately > > > > check for len == 0 and return. > > > > > > > > While this is mostly harmless, it is spurious and not completely > > > > without side effect. A filemap write call can submit I/O (but not > > > > wait on it) when the specified end byte precedes the start but > > > > happens to land on the same aligned page boundary, which can occur > > > > from __generic_remap_file_range_prep() when len is 0. > > > > > > > > The dedupe path already has a len == 0 check to break out before doing > > > > range comparisons. Lift this check a bit earlier in the function to > > > > cover the general case of len == 0 and avoid the unnecessary work. > > > > > > > > Signed-off-by: Brian Foster <bfoster@redhat.com> > > > > > > Looks correct, > > > Reviewed-by: Darrick J. Wong <djwong@kernel.org> > > > > > > Should there be an(other) "if (!*len) return 0;" after the > > > generic_remap_check_len call to skip the mtime update if the remap > > > request gets shortened to avoid remapping an unaligned eofblock into the > > > middle of the destination file? > > > > > > > Looks sensible to me, though I guess I would do something like the > > appended diff. Do you want to just fold that into this patch? > > Yes, could you fold it in and send a v2 with my rvb on it, please? > Sure. I'll change both lines to do 'if (ret || *len == 0),' not sure why I didn't do that the first time.. Brian > --D > > > Brian > > > > --- 8< --- > > > > diff --git a/fs/remap_range.c b/fs/remap_range.c > > index 32ea992f9acc..2f236c9c5802 100644 > > --- a/fs/remap_range.c > > +++ b/fs/remap_range.c > > @@ -347,7 +347,7 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, > > > > ret = generic_remap_check_len(inode_in, inode_out, pos_out, len, > > remap_flags); > > - if (ret) > > + if (ret || *len == 0) > > return ret; > > > > /* If can't alter the file contents, we're done. */ > > >
diff --git a/fs/remap_range.c b/fs/remap_range.c index 654912d06862..32ea992f9acc 100644 --- a/fs/remap_range.c +++ b/fs/remap_range.c @@ -306,6 +306,8 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, remap_flags); if (ret) return ret; + if (*len == 0) + return 0; /* Wait for the completion of any pending IOs on both files */ inode_dio_wait(inode_in); @@ -328,9 +330,6 @@ __generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, if (remap_flags & REMAP_FILE_DEDUP) { bool is_same = false; - if (*len == 0) - return 0; - if (!IS_DAX(inode_in)) ret = vfs_dedupe_file_range_compare(file_in, pos_in, file_out, pos_out, *len, &is_same);
generic_remap_checks() can reduce the effective request length (i.e., after the reflink extend to EOF case is handled) down to zero. If this occurs, __generic_remap_file_range_prep() proceeds through dio serialization, file mapping flush calls, and may invoke file_modified() before returning back to the filesystem caller, all of which immediately check for len == 0 and return. While this is mostly harmless, it is spurious and not completely without side effect. A filemap write call can submit I/O (but not wait on it) when the specified end byte precedes the start but happens to land on the same aligned page boundary, which can occur from __generic_remap_file_range_prep() when len is 0. The dedupe path already has a len == 0 check to break out before doing range comparisons. Lift this check a bit earlier in the function to cover the general case of len == 0 and avoid the unnecessary work. Signed-off-by: Brian Foster <bfoster@redhat.com> --- fs/remap_range.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)