DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 613C120657
Date:   Wed, 31 Oct 2018 14:29:45 -0400
From:   "J. Bruce Fields" <bfields@fieldses.org>
To:     Olga Kornievskaia <olga.kornievskaia@gmail.com>
Cc:     "J. Bruce Fields" <bfields@redhat.com>,
        linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 01/13] fs: Don't copy beyond the end of the file
Message-ID: <20181031182945.GC3377@fieldses.org>
References: <20181019152905.32418-1-olga.kornievskaia@gmail.com>
 <20181019152905.32418-2-olga.kornievskaia@gmail.com>
 <20181031165430.GA3377@fieldses.org>
 <CAN-5tyHTZV9LYnfD9Ag_pSdWA2Zs69JNvVBjHPQTMnDm2kRuEQ@mail.gmail.com>
 <20181031175409.GB3377@fieldses.org>
 <CAN-5tyGo8BeWtGPZTd=A19+ZG3yFcGu_uu=s1MRiF6F-c+0bFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN-5tyGo8BeWtGPZTd=A19+ZG3yFcGu_uu=s1MRiF6F-c+0bFw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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.