On Fri, 2018-10-19 at 11:29 -0400, Olga Kornievskaia wrote:
> From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
>
> Signed-off-by: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
> ---
> fs/read_write.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 39b4a21..c60790f 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1570,6 +1570,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> if (unlikely(ret))
> return ret;
>
> + if (pos_in >= i_size_read(inode_in))
> + return -EINVAL;
> +
> if (!(file_in->f_mode & FMODE_READ) ||
> !(file_out->f_mode & FMODE_WRITE) ||
> (file_out->f_flags & O_APPEND))
The patch description could use a bit more fleshing-out. The
copy_file_range manpage says:
EINVAL Requested range extends beyond the end of the source file; or the flags argument is not 0.
So I guess this is intended to satisfy that requirement? If so,
i_size_read is just going to return whatever is in inode->isize.
Could a copy_file_range call end up getting issued to copy from a file
that is already open on a range that it doesn't know about yet? i.e.
where the inode cache has not yet been updated.
It seems like that could on network filesystems (like NFS). Would this
be better handled in ->copy_file_range instead, where the driver could
make a better determination of the file size?
--
Jeff Layton <jlayton@xxxxxxxxxx>
