Message ID | 20190410111359.5243-1-bfoster@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | fsx: test copy_file_range() using non-zero length copy | expand |
On Wed, Apr 10, 2019 at 07:13:59AM -0400, Brian Foster wrote: > The copy_file_range() test detection code performs a zero-length > copy to determine whether to perform such calls during the test run. > While this detects the common case of syscall availability, > copy_file_range() has a somewhat variable implementation on the > kernel side that can depend on certain per-filesystem features, etc. > In some implementations, a zero length copy can shortcut and return > success before ever invoking per-filesystem functionality and thus > not thoroughly testing the copy mechanism on the current system. > This can cause the test detection code to pass only to run into an > immediate failure on the first copy_file_range() call during the > test. > > Tweak test_copy_range() to perform a small single byte copy to avoid > this problem. Also fix a typo bug in the errno check of the clone > range detection logic. > > Signed-off-by: Brian Foster <bfoster@redhat.com> Looks ok, Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > ltp/fsx.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/ltp/fsx.c b/ltp/fsx.c > index 391824bf..06d08e4e 100644 > --- a/ltp/fsx.c > +++ b/ltp/fsx.c > @@ -1364,7 +1364,7 @@ test_clone_range(void) > }; > > if (ioctl(fd, FICLONERANGE, &fcr) && > - (errno = EOPNOTSUPP || errno == ENOTTY)) { > + (errno == EOPNOTSUPP || errno == ENOTTY)) { > if (!quiet) > fprintf(stderr, > "main: filesystem does not support " > @@ -1581,9 +1581,9 @@ do_dedupe_range(unsigned offset, unsigned length, unsigned dest) > int > test_copy_range(void) > { > - loff_t o1 = 0, o2 = 0; > + loff_t o1 = 0, o2 = 1; > > - if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 0, 0) == -1 && > + if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 && > (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) { > if (!quiet) > fprintf(stderr, > -- > 2.17.2 >
diff --git a/ltp/fsx.c b/ltp/fsx.c index 391824bf..06d08e4e 100644 --- a/ltp/fsx.c +++ b/ltp/fsx.c @@ -1364,7 +1364,7 @@ test_clone_range(void) }; if (ioctl(fd, FICLONERANGE, &fcr) && - (errno = EOPNOTSUPP || errno == ENOTTY)) { + (errno == EOPNOTSUPP || errno == ENOTTY)) { if (!quiet) fprintf(stderr, "main: filesystem does not support " @@ -1581,9 +1581,9 @@ do_dedupe_range(unsigned offset, unsigned length, unsigned dest) int test_copy_range(void) { - loff_t o1 = 0, o2 = 0; + loff_t o1 = 0, o2 = 1; - if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 0, 0) == -1 && + if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 && (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) { if (!quiet) fprintf(stderr,
The copy_file_range() test detection code performs a zero-length copy to determine whether to perform such calls during the test run. While this detects the common case of syscall availability, copy_file_range() has a somewhat variable implementation on the kernel side that can depend on certain per-filesystem features, etc. In some implementations, a zero length copy can shortcut and return success before ever invoking per-filesystem functionality and thus not thoroughly testing the copy mechanism on the current system. This can cause the test detection code to pass only to run into an immediate failure on the first copy_file_range() call during the test. Tweak test_copy_range() to perform a small single byte copy to avoid this problem. Also fix a typo bug in the errno check of the clone range detection logic. Signed-off-by: Brian Foster <bfoster@redhat.com> --- ltp/fsx.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)