Re: [PATCH v1 01/13] fs: Don't copy beyond the end of the file

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Oct 31, 2018 at 02:01:45PM -0400, Olga Kornievskaia wrote:
> On Wed, Oct 31, 2018 at 1:54 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Wed, Oct 31, 2018 at 01:07:11PM -0400, Olga Kornievskaia wrote:
> > > On Wed, Oct 31, 2018 at 12:54 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> > > >
> > > > On Fri, Oct 19, 2018 at 11:28:53AM -0400, Olga Kornievskaia wrote:
> > > > > From: Anna Schumaker <Anna.Schumaker@Netapp.com>
> > > >
> > > > I have some idea we've had some discussion about this before, but if so
> > > > I've forgotten the conclusion.  Could we have more of a changelog?:
> > > >
> > > >         - isn't there a race condition, or is there something preventing
> > > >           the file size from changing here?
> > >
> > > No there is nothing preventing the size from changing. Just like there
> > > is nothing that prevents the file from changing if you are doing a
> > > traditional copy either.
> > >
> > > >         - why are we doing this?  Does this change the behavior of
> > > >           copy_file_range()?
> > >
> > > We are doing this because 1. NFS spec and 2. copy_file_range semantics
> > > mandate that too. There is a whole different discussion under the
> > > client-side patch for this where the plan now is that VFS themselves
> > > are interested in making sure they are indeed enforcing the check
> > > stated by the documentation of copy_file_range call which states
> > > "copying a range beyond the end of the file" is EINVAL. I recall you
> > > argued for a "short" read instead of a EINVAL but unless VFS community
> > > is convinced to change it it'll be enforced (soon).
> >
> > OK.  Let's just make sure the reasoning's mentioned in the changelog,
> > whatever we do.
> 
> By the changelog, you mean the commit message?

Right.--b.