copy_file_range() errno changes introduced in v5.3-rc1

copy_file_range() errno changes introduced in v5.3-rc1

[Petr Vorel]

Hi Amir,

I'm going to fix LTP test copy_file_range02 before upcoming LTP release.
There are some returning errno changes introduced in v5.3-rc1, part of commit 40f06c799539
("Merge tag 'copy-file-range-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux").
These changes looks pretty obvious as wanted, but can you please confirm it they were intentional?

* 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.
* 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.

Thanks for info.

Kind regards,
Petr

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Darrick J. Wong]

On Thu, Sep 26, 2019 at 05:56:08PM +0200, Petr Vorel wrote:
> Hi Amir,
> 
> I'm going to fix LTP test copy_file_range02 before upcoming LTP release.
> There are some returning errno changes introduced in v5.3-rc1, part of commit 40f06c799539
> ("Merge tag 'copy-file-range-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux").
> These changes looks pretty obvious as wanted, but can you please confirm it they were intentional?
> 
> * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.
> * 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.

I'm not Amir, but by my recollection, yes, those are intentional. :)

--D

> Thanks for info.
> 
> Kind regards,
> Petr

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Petr Vorel]

Hi Darrick,

> On Thu, Sep 26, 2019 at 05:56:08PM +0200, Petr Vorel wrote:
> > Hi Amir,

> > I'm going to fix LTP test copy_file_range02 before upcoming LTP release.
> > There are some returning errno changes introduced in v5.3-rc1, part of commit 40f06c799539
> > ("Merge tag 'copy-file-range-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux").
> > These changes looks pretty obvious as wanted, but can you please confirm it they were intentional?

> > * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.
> > * 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.

> I'm not Amir, but by my recollection, yes, those are intentional. :)
Thanks for a quick confirmation.

> --D

Kind regards,
Petr

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Amir Goldstein]

On Thu, Sep 26, 2019 at 7:19 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Darrick,
>
> > On Thu, Sep 26, 2019 at 05:56:08PM +0200, Petr Vorel wrote:
> > > Hi Amir,
>
> > > I'm going to fix LTP test copy_file_range02 before upcoming LTP release.
> > > There are some returning errno changes introduced in v5.3-rc1, part of commit 40f06c799539
> > > ("Merge tag 'copy-file-range-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux").
> > > These changes looks pretty obvious as wanted, but can you please confirm it they were intentional?
>
> > > * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.

Started to return EXDEV?? quite the opposite.
But LTP tests where already adapted to that behavior AFAICT:
15cac7b46 syscalls/copy_file_range01: add cross-device test


> > > * 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.
>
> > I'm not Amir, but by my recollection, yes, those are intentional. :)
> Thanks for a quick confirmation.
>

Which reminds me - I forgot to send the man pages patch out to maintainer:
https://lore.kernel.org/linux-fsdevel/20190529174318.22424-15-amir73il@gmail.com/

At least according to man page -EACCES is also possible.

Thanks,
Amir.

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Amir Goldstein]

On Thu, Sep 26, 2019 at 7:33 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Sep 26, 2019 at 7:19 PM Petr Vorel <pvorel@suse.cz> wrote:
> >
> > Hi Darrick,
> >
> > > On Thu, Sep 26, 2019 at 05:56:08PM +0200, Petr Vorel wrote:
> > > > Hi Amir,
> >
> > > > I'm going to fix LTP test copy_file_range02 before upcoming LTP release.
> > > > There are some returning errno changes introduced in v5.3-rc1, part of commit 40f06c799539
> > > > ("Merge tag 'copy-file-range-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux").
> > > > These changes looks pretty obvious as wanted, but can you please confirm it they were intentional?
> >
> > > > * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.
>
> Started to return EXDEV?? quite the opposite.
> But LTP tests where already adapted to that behavior AFAICT:
> 15cac7b46 syscalls/copy_file_range01: add cross-device test
>
>
> > > > * 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.
> >
> > > I'm not Amir, but by my recollection, yes, those are intentional. :)
> > Thanks for a quick confirmation.
> >
>
> Which reminds me - I forgot to send the man pages patch out to maintainer:
> https://lore.kernel.org/linux-fsdevel/20190529174318.22424-15-amir73il@gmail.com/
>
> At least according to man page -EACCES is also possible.
>

But it looks like man page update is wrong.
I'll fix it and post.

Thanks,
Amir.

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Petr Vorel]

Hi Amir,

> > > > * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.

> Started to return EXDEV?? quite the opposite.
> But LTP tests where already adapted to that behavior AFAICT:
> 15cac7b46 syscalls/copy_file_range01: add cross-device test
I'm talking about copy_file_range02 (15cac7b46 changes copy_file_range01).

Anyway, the problem which I want to fix is a backward compatibility for v5.2 and
older to fix errors like this:

copy_file_range02.c:102: INFO: Test #7: overlaping range
copy_file_range02.c:134: FAIL: copy_file_range returned wrong value: 16
copy_file_range02.c:102: INFO: Test #8: block device
copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EINVAL, but got: EXDEV (18)
copy_file_range02.c:102: INFO: Test #9: char device
copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EINVAL, but got: EXDEV (18)
...
copy_file_range02.c:102: INFO: Test #11: max length lenght
copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EOVERFLOW, but got: EINVAL (22)
copy_file_range02.c:102: INFO: Test #12: max file size
copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EFBIG, but got: EINVAL (22)

LTP hasn't defined yet any policy about changing errnos,
as it's probably best to check whether change was intentional
(like your obvious fixes) or not.

> > > > * 96e6e8f4a68d ("vfs: add missing checks to copy_file_range") started to return -EPERM, -ETXTBSY, -EOVERFLOW.

> > > I'm not Amir, but by my recollection, yes, those are intentional. :)
> > Thanks for a quick confirmation.


> Which reminds me - I forgot to send the man pages patch out to maintainer:
> https://lore.kernel.org/linux-fsdevel/20190529174318.22424-15-amir73il@gmail.com/

> At least according to man page -EACCES is also possible.
Thanks for fixing man :).

Kind regards,
Petr

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Amir Goldstein]

On Thu, Sep 26, 2019 at 8:57 PM Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Amir,
>
> > > > > * 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") started to return -EXDEV.
>
> > Started to return EXDEV?? quite the opposite.
> > But LTP tests where already adapted to that behavior AFAICT:
> > 15cac7b46 syscalls/copy_file_range01: add cross-device test
> I'm talking about copy_file_range02 (15cac7b46 changes copy_file_range01).
>
> Anyway, the problem which I want to fix is a backward compatibility for v5.2 and
> older to fix errors like this:
>
> copy_file_range02.c:102: INFO: Test #7: overlaping range
> copy_file_range02.c:134: FAIL: copy_file_range returned wrong value: 16
> copy_file_range02.c:102: INFO: Test #8: block device
> copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EINVAL, but got: EXDEV (18)
> copy_file_range02.c:102: INFO: Test #9: char device
> copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EINVAL, but got: EXDEV (18)
> ...
> copy_file_range02.c:102: INFO: Test #11: max length lenght
> copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EOVERFLOW, but got: EINVAL (22)
> copy_file_range02.c:102: INFO: Test #12: max file size
> copy_file_range02.c:128: FAIL: copy_file_range failed unexpectedly; expected EFBIG, but got: EINVAL (22)
>
> LTP hasn't defined yet any policy about changing errnos,
> as it's probably best to check whether change was intentional
> (like your obvious fixes) or not.
>

IIUC, copy_file_range02 was written after v5.3 changes to verify that
copy_file_range
stays unbroken.
As such, I would suggest that you check if kernel supports cross-fs copy, like
copy_file_range01 does and if it doesn't, skip the test entirely.
If some one ever backports cross-fs copy to any distro stable kernel, then one
would better also backkport all of those API fixes, otherwise test will fail.

Thanks,
Amir.

Re: copy_file_range() errno changes introduced in v5.3-rc1

[Petr Vorel]

Hi Amir,

> > LTP hasn't defined yet any policy about changing errnos,
> > as it's probably best to check whether change was intentional
> > (like your obvious fixes) or not.


> IIUC, copy_file_range02 was written after v5.3 changes to verify that
> copy_file_range
> stays unbroken.
> As such, I would suggest that you check if kernel supports cross-fs copy, like
> copy_file_range01 does and if it doesn't, skip the test entirely.
> If some one ever backports cross-fs copy to any distro stable kernel, then one
> would better also backkport all of those API fixes, otherwise test will fail.
Thanks for a tip, I'll send a patch today.

> Thanks,
> Amir.

Kind regards,
Petr