* [LTP] copy_file_range() errno changes introduced in v5.3-rc1
@ 2019-09-26 16:33 ` Amir Goldstein
0 siblings, 0 replies; 16+ messages in thread
From: Amir Goldstein @ 2019-09-26 16:33 UTC (permalink / raw)
To: ltp
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: copy_file_range() errno changes introduced in v5.3-rc1
2019-09-26 16:33 ` [LTP] " Amir Goldstein
@ 2019-09-26 16:50 ` Amir Goldstein
-1 siblings, 0 replies; 16+ messages in thread
From: Amir Goldstein @ 2019-09-26 16:50 UTC (permalink / raw)
To: Petr Vorel
Cc: Darrick J. Wong, Dave Chinner, Cyril Hrubis, linux-xfs,
linux-fsdevel, LTP List, Michael Kerrisk (man-pages)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [LTP] copy_file_range() errno changes introduced in v5.3-rc1
@ 2019-09-26 16:50 ` Amir Goldstein
0 siblings, 0 replies; 16+ messages in thread
From: Amir Goldstein @ 2019-09-26 16:50 UTC (permalink / raw)
To: ltp
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: copy_file_range() errno changes introduced in v5.3-rc1
2019-09-26 16:33 ` [LTP] " Amir Goldstein
@ 2019-09-26 17:57 ` Petr Vorel
-1 siblings, 0 replies; 16+ messages in thread
From: Petr Vorel @ 2019-09-26 17:57 UTC (permalink / raw)
To: Amir Goldstein
Cc: Darrick J. Wong, Dave Chinner, Cyril Hrubis, linux-xfs,
linux-fsdevel, LTP List, Michael Kerrisk (man-pages)
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
^ permalink raw reply [flat|nested] 16+ messages in thread* [LTP] copy_file_range() errno changes introduced in v5.3-rc1
@ 2019-09-26 17:57 ` Petr Vorel
0 siblings, 0 replies; 16+ messages in thread
From: Petr Vorel @ 2019-09-26 17:57 UTC (permalink / raw)
To: ltp
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: copy_file_range() errno changes introduced in v5.3-rc1
2019-09-26 17:57 ` [LTP] " Petr Vorel
@ 2019-09-26 18:07 ` Amir Goldstein
-1 siblings, 0 replies; 16+ messages in thread
From: Amir Goldstein @ 2019-09-26 18:07 UTC (permalink / raw)
To: Petr Vorel
Cc: Darrick J. Wong, Dave Chinner, Cyril Hrubis, linux-xfs,
linux-fsdevel, LTP List, Michael Kerrisk (man-pages)
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* [LTP] copy_file_range() errno changes introduced in v5.3-rc1
@ 2019-09-26 18:07 ` Amir Goldstein
0 siblings, 0 replies; 16+ messages in thread
From: Amir Goldstein @ 2019-09-26 18:07 UTC (permalink / raw)
To: ltp
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: copy_file_range() errno changes introduced in v5.3-rc1
2019-09-26 18:07 ` [LTP] " Amir Goldstein
@ 2019-09-27 8:25 ` Petr Vorel
-1 siblings, 0 replies; 16+ messages in thread
From: Petr Vorel @ 2019-09-27 8:25 UTC (permalink / raw)
To: Amir Goldstein
Cc: Darrick J. Wong, Dave Chinner, Cyril Hrubis, linux-xfs,
linux-fsdevel, LTP List, Michael Kerrisk (man-pages)
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [LTP] copy_file_range() errno changes introduced in v5.3-rc1
@ 2019-09-27 8:25 ` Petr Vorel
0 siblings, 0 replies; 16+ messages in thread
From: Petr Vorel @ 2019-09-27 8:25 UTC (permalink / raw)
To: ltp
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
^ permalink raw reply [flat|nested] 16+ messages in thread