On Tue, Jun 25, 2019 at 1:29 PM Yang Xu <xuyang2018.jy@xxxxxxxxxxxxxx> wrote:
>
> on 2019/06/18 23:11, Darrick J. Wong wrote:
>
> > On Tue, Jun 18, 2019 at 11:02:42AM -0400, Theodore Ts'o wrote:
> >> On Tue, Jun 18, 2019 at 12:16:45PM +0300, Amir Goldstein wrote:
> >>> On Tue, Jun 18, 2019 at 12:02 PM Murphy Zhou<jencce.kernel@xxxxxxxxx> wrote:
> >>>> Would you mind updating sha1 after it get merged to Linus tree?
> >>>>
> >>>> That would be helpful for people tracking this issue.
> >>>>
> >>> This is the commit id in linux-next and expected to stay the same
> >>> when the fix is merged to Linus tree for 5.3.
> >> When I talked to Darrick last week, that was *not* the sense I got
> >> from him. It's not necessarily guaranteed to be stable just yet...
> > Darrick hasn't gotten any complaints about the copy-file-range-fixes
> > branch (which has been in for-next for a week now), so he thinks that
> > commit id (a31713517dac) should be stable from here on out.
> >
> > (Note that doesn't guarantee that Linus will pull said branch...)
> >
> > --D
> Hi Amir
>
> The kernel fix commit message is right? :-) Because when I backport this patch into 5.2.0-rc6+ kernel,
> generic/554(553) also fails, it should be commit a5544984af4 (vfs: add missing checks to copy_file_range).
> By the way, a31713517dac ("vfs: introduce generic_file_rw_checks()") doesn't check for immutable and swap file.
>
> I think we can change this message after the fix is merged to Linus tree for 5.3. What do you think about it?
You are right. Documented commit is wrong.
The correct commit in linux-next is:
96e6e8f4a68d ("vfs: add missing checks to copy_file_range")
(Not sure where you got a5544984af4 from?)
Let's fix that after the commit is upstream.
Obviously, you would need to backport the entire series and not just this
one commit to stable kernel.
Thanks,
Amir.
