All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <lhenriques@suse.de>
To: kernel test robot <oliver.sang@intel.com>
Cc: 0day robot <lkp@intel.com>,
	Nicolas Boichat <drinkcat@chromium.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Olga Kornievskaia <aglo@umich.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [vfs]  94a4dd06a6: xfstests.generic.263.fail
Date: Fri, 14 May 2021 12:05:31 +0100	[thread overview]
Message-ID: <877dk1zibo.fsf@suse.de> (raw)
In-Reply-To: <20210513135644.GE20142@xsang-OptiPlex-9020> (kernel test robot's message of "Thu, 13 May 2021 21:56:44 +0800")

kernel test robot <oliver.sang@intel.com> writes:

> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 94a4dd06a6bbf3978b0bb1dddc2d8ec4e5bcad26 ("[PATCH v9] vfs: fix copy_file_range regression in cross-fs copies")
> url: https://github.com/0day-ci/linux/commits/Luis-Henriques/vfs-fix-copy_file_range-regression-in-cross-fs-copies/20210510-170804
> base: https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git for-next
>
> in testcase: xfstests
> version: xfstests-x86_64-73c0871-1_20210401
> with following parameters:
>
> 	disk: 4HDD
> 	fs: xfs
> 	test: generic-group-13
> 	ucode: 0x21
>
> test-description: xfstests is a regression test suite for xfs and other files ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
>
> on test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <oliver.sang@intel.com>
>
> 2021-05-11 11:28:23 export TEST_DIR=/fs/sda1
> 2021-05-11 11:28:23 export TEST_DEV=/dev/sda1
> 2021-05-11 11:28:23 export FSTYP=xfs
> 2021-05-11 11:28:23 export SCRATCH_MNT=/fs/scratch
> 2021-05-11 11:28:23 mkdir /fs/scratch -p
> 2021-05-11 11:28:23 export SCRATCH_DEV=/dev/sda4
> 2021-05-11 11:28:23 export SCRATCH_LOGDEV=/dev/sda2
> 2021-05-11 11:28:23 sed "s:^:generic/:" //lkp/benchmarks/xfstests/tests/generic-group-13
> 2021-05-11 11:28:23 ./check generic/260 generic/261 generic/262 generic/263 generic/264 generic/265 generic/266 generic/267 generic/268 generic/269 generic/270 generic/271 generic/272 generic/273 generic/274 generic/275 generic/276 generic/277 generic/278 generic/279
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 lkp-ivb-d02 5.12.0-rc6-00061-g94a4dd06a6bb #1 SMP Tue May 11 00:58:17 CST 2021
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/sda4
> MOUNT_OPTIONS -- /dev/sda4 /fs/scratch
>
> generic/260	[not run] FITRIM not supported on /fs/scratch
> generic/261	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/262	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/263	[failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//generic/263.out.bad)
>     --- tests/generic/263.out	2021-04-01 03:07:08.000000000 +0000
>     +++ /lkp/benchmarks/xfstests/results//generic/263.out.bad	2021-05-11 11:28:29.773460096 +0000
>     @@ -1,3 +1,32 @@
>      QA output created by 263
>      fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
>     -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
>     +Seed set to 1
>     +main: filesystem does not support clone range, disabling!
>     +main: filesystem does not support dedupe range, disabling!
>     +skipping zero size read
>     ...
>     (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/263.out /lkp/benchmarks/xfstests/results//generic/263.out.bad'  to see the entire diff)
> generic/264	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/265	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/266	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/267	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/268	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/269	 48s
> generic/270	 61s
> generic/271	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/272	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/273	 17s
> generic/274	 14s
> generic/275	 11s
> generic/276	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/277	 3s
> generic/278	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/279	[not run] Reflink not supported by scratch filesystem type: xfs
> Ran: generic/260 generic/261 generic/262 generic/263 generic/264 generic/265 generic/266 generic/267 generic/268 generic/269 generic/270 generic/271 generic/272 generic/273 generic/274 generic/275 generic/276 generic/277 generic/278 generic/279
> Not run: generic/260 generic/261 generic/262 generic/264 generic/265 generic/266 generic/267 generic/268 generic/271 generic/272 generic/276 generic/278 generic/279
> Failures: generic/263
> Failed 1 of 20 tests

OK, I see what's going on.  There are 2 issues: one with patch and another
one with the test itself.

The CFR syscall should have been disabled in this test but it isn't
because the test tries to copy 1 byte from a zero-sized file:

int
test_copy_range(void)
{
	loff_t o1 = 0, o2 = 1;

	if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 &&
	    (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) {
		if (!quiet)
			fprintf(stderr,
				"main: filesystem does not support "
				"copy range, disabling!\n");
		return 0;
	}

	return 1;
}

The syscall is doing an early '0' return because the file size is < len.

Fixing the kernel should probably be as easy as removing the
short-circuiting check in vfs_copy_file_range():

	if (len == 0)
		return 0;

This will force the filesystems code to handle '0' size copies but will
also make sure -EOPNOTSUPP is returned in this case.

Alternatively, we could have something like:

	if (len == 0) {
		if (file_out->f_op->copy_file_range)
			return 0;
		else
			return -EOPNOTSUPP;
	}

What do you guys think is the right thing to do?

Additionally, the test should also be fixed with something as the patch
bellow.  By making sure we have 1 byte to copy we also ensure the syscall
will return -EOPNOTSUPP, even with the current version of the patch.

Cheers,
-- 
Luis

diff --git a/ltp/fsx.c b/ltp/fsx.c
index cd0bae55aeb8..97db594ae142 100644
--- a/ltp/fsx.c
+++ b/ltp/fsx.c
@@ -1596,6 +1596,10 @@ int
 test_copy_range(void)
 {
 	loff_t o1 = 0, o2 = 1;
+	int ret = 1;
+
+	/* Make sure we have 1 byte to copy */
+	ftruncate(fd, 1);
 
 	if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 &&
 	    (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) {
@@ -1603,10 +1607,13 @@ test_copy_range(void)
 			fprintf(stderr,
 				"main: filesystem does not support "
 				"copy range, disabling!\n");
-		return 0;
+		ret = 0;
 	}
 
-	return 1;
+	/* Restore file size */
+	ftruncate(fd, 0);
+
+	return ret;
 }
 
 void

WARNING: multiple messages have this Message-ID (diff)
From: Luis Henriques <lhenriques@suse.de>
To: lkp@lists.01.org
Subject: Re: [vfs] 94a4dd06a6: xfstests.generic.263.fail
Date: Fri, 14 May 2021 12:05:31 +0100	[thread overview]
Message-ID: <877dk1zibo.fsf@suse.de> (raw)
In-Reply-To: <20210513135644.GE20142@xsang-OptiPlex-9020>

[-- Attachment #1: Type: text/plain, Size: 6552 bytes --]

kernel test robot <oliver.sang@intel.com> writes:

> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 94a4dd06a6bbf3978b0bb1dddc2d8ec4e5bcad26 ("[PATCH v9] vfs: fix copy_file_range regression in cross-fs copies")
> url: https://github.com/0day-ci/linux/commits/Luis-Henriques/vfs-fix-copy_file_range-regression-in-cross-fs-copies/20210510-170804
> base: https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git for-next
>
> in testcase: xfstests
> version: xfstests-x86_64-73c0871-1_20210401
> with following parameters:
>
> 	disk: 4HDD
> 	fs: xfs
> 	test: generic-group-13
> 	ucode: 0x21
>
> test-description: xfstests is a regression test suite for xfs and other files ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
>
> on test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <oliver.sang@intel.com>
>
> 2021-05-11 11:28:23 export TEST_DIR=/fs/sda1
> 2021-05-11 11:28:23 export TEST_DEV=/dev/sda1
> 2021-05-11 11:28:23 export FSTYP=xfs
> 2021-05-11 11:28:23 export SCRATCH_MNT=/fs/scratch
> 2021-05-11 11:28:23 mkdir /fs/scratch -p
> 2021-05-11 11:28:23 export SCRATCH_DEV=/dev/sda4
> 2021-05-11 11:28:23 export SCRATCH_LOGDEV=/dev/sda2
> 2021-05-11 11:28:23 sed "s:^:generic/:" //lkp/benchmarks/xfstests/tests/generic-group-13
> 2021-05-11 11:28:23 ./check generic/260 generic/261 generic/262 generic/263 generic/264 generic/265 generic/266 generic/267 generic/268 generic/269 generic/270 generic/271 generic/272 generic/273 generic/274 generic/275 generic/276 generic/277 generic/278 generic/279
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 lkp-ivb-d02 5.12.0-rc6-00061-g94a4dd06a6bb #1 SMP Tue May 11 00:58:17 CST 2021
> MKFS_OPTIONS  -- -f -bsize=4096 /dev/sda4
> MOUNT_OPTIONS -- /dev/sda4 /fs/scratch
>
> generic/260	[not run] FITRIM not supported on /fs/scratch
> generic/261	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/262	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/263	[failed, exit status 1]- output mismatch (see /lkp/benchmarks/xfstests/results//generic/263.out.bad)
>     --- tests/generic/263.out	2021-04-01 03:07:08.000000000 +0000
>     +++ /lkp/benchmarks/xfstests/results//generic/263.out.bad	2021-05-11 11:28:29.773460096 +0000
>     @@ -1,3 +1,32 @@
>      QA output created by 263
>      fsx -N 10000 -o 8192 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
>     -fsx -N 10000 -o 128000 -l 500000 -r PSIZE -t BSIZE -w BSIZE -Z
>     +Seed set to 1
>     +main: filesystem does not support clone range, disabling!
>     +main: filesystem does not support dedupe range, disabling!
>     +skipping zero size read
>     ...
>     (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/263.out /lkp/benchmarks/xfstests/results//generic/263.out.bad'  to see the entire diff)
> generic/264	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/265	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/266	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/267	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/268	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/269	 48s
> generic/270	 61s
> generic/271	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/272	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/273	 17s
> generic/274	 14s
> generic/275	 11s
> generic/276	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/277	 3s
> generic/278	[not run] Reflink not supported by scratch filesystem type: xfs
> generic/279	[not run] Reflink not supported by scratch filesystem type: xfs
> Ran: generic/260 generic/261 generic/262 generic/263 generic/264 generic/265 generic/266 generic/267 generic/268 generic/269 generic/270 generic/271 generic/272 generic/273 generic/274 generic/275 generic/276 generic/277 generic/278 generic/279
> Not run: generic/260 generic/261 generic/262 generic/264 generic/265 generic/266 generic/267 generic/268 generic/271 generic/272 generic/276 generic/278 generic/279
> Failures: generic/263
> Failed 1 of 20 tests

OK, I see what's going on.  There are 2 issues: one with patch and another
one with the test itself.

The CFR syscall should have been disabled in this test but it isn't
because the test tries to copy 1 byte from a zero-sized file:

int
test_copy_range(void)
{
	loff_t o1 = 0, o2 = 1;

	if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 &&
	    (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) {
		if (!quiet)
			fprintf(stderr,
				"main: filesystem does not support "
				"copy range, disabling!\n");
		return 0;
	}

	return 1;
}

The syscall is doing an early '0' return because the file size is < len.

Fixing the kernel should probably be as easy as removing the
short-circuiting check in vfs_copy_file_range():

	if (len == 0)
		return 0;

This will force the filesystems code to handle '0' size copies but will
also make sure -EOPNOTSUPP is returned in this case.

Alternatively, we could have something like:

	if (len == 0) {
		if (file_out->f_op->copy_file_range)
			return 0;
		else
			return -EOPNOTSUPP;
	}

What do you guys think is the right thing to do?

Additionally, the test should also be fixed with something as the patch
bellow.  By making sure we have 1 byte to copy we also ensure the syscall
will return -EOPNOTSUPP, even with the current version of the patch.

Cheers,
-- 
Luis

diff --git a/ltp/fsx.c b/ltp/fsx.c
index cd0bae55aeb8..97db594ae142 100644
--- a/ltp/fsx.c
+++ b/ltp/fsx.c
@@ -1596,6 +1596,10 @@ int
 test_copy_range(void)
 {
 	loff_t o1 = 0, o2 = 1;
+	int ret = 1;
+
+	/* Make sure we have 1 byte to copy */
+	ftruncate(fd, 1);
 
 	if (syscall(__NR_copy_file_range, fd, &o1, fd, &o2, 1, 0) == -1 &&
 	    (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTTY)) {
@@ -1603,10 +1607,13 @@ test_copy_range(void)
 			fprintf(stderr,
 				"main: filesystem does not support "
 				"copy range, disabling!\n");
-		return 0;
+		ret = 0;
 	}
 
-	return 1;
+	/* Restore file size */
+	ftruncate(fd, 0);
+
+	return ret;
 }
 
 void

  reply	other threads:[~2021-05-14 11:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10  9:08 [PATCH v9] vfs: fix copy_file_range regression in cross-fs copies Luis Henriques
2021-05-13 13:56 ` [vfs] 94a4dd06a6: xfstests.generic.263.fail kernel test robot
2021-05-13 13:56   ` kernel test robot
2021-05-14 11:05   ` Luis Henriques [this message]
2021-05-14 11:05     ` Luis Henriques
2021-05-18 11:10     ` [PATCH] vfs: fix early copy_file_range return when len is zero Luis Henriques
2021-06-30 15:46     ` [vfs] 94a4dd06a6: xfstests.generic.263.fail Amir Goldstein
2021-06-30 15:46       ` Amir Goldstein
2021-06-30 16:06       ` Luis Henriques
2021-06-30 16:06         ` Luis Henriques

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dk1zibo.fsf@suse.de \
    --to=lhenriques@suse.de \
    --cc=aglo@umich.edu \
    --cc=amir73il@gmail.com \
    --cc=drinkcat@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=oliver.sang@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.