On Fri, Oct 5, 2018 at 3:46 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
>
> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>
> Use the new CLONE_RANGE_EOF flag to explicitly declare that the caller
> wants the clone implementation to set *len appropriately once the files
> are locked.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> ---
> fs/read_write.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 7cfff497263b..4eaea52f70a8 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1747,11 +1747,12 @@ int vfs_clone_file_prep(struct file *file_in, loff_t pos_in,
>
> isize = i_size_read(inode_in);
>
> - /* Zero length dedupe exits immediately; reflink goes to EOF. */
> - if (*len == 0) {
> - if (is_dedupe || pos_in == isize)
> - return 0;
> - if (pos_in > isize)
> + /*
> + * If the caller asked to go all the way to the end of the source file,
> + * set *len now that we have the file locked.
> + */
> + if ((flags & CLONERANGE_EOF) && *len == 0) {
> + if (pos_in >= isize)
> return -EINVAL;
Slight change of behavior with clone of 0 bytes at EOF.
Is that intentional?
Does not change behavior through the entire series?
Please drop a work about this in commit message.
Thanks,
Amir.
