[PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range

[PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range

[Nicolas Boichat]

We hit an issue when upgrading Go compiler from 1.13 to 1.15 [1],
as we use Go's `io.Copy` to copy the content of
`/sys/kernel/debug/tracing/trace` to a temporary file.

Under the hood, Go 1.15 uses `copy_file_range` syscall to
optimize the copy operation. However, that fails to copy any
content when the input file is from tracefs, with an apparent
size of 0 (but there is still content when you `cat` it, of
course).

From discussions in [2][3], it is clear that copy_file_range
cannot be properly implemented on filesystems where the content
is generated at runtime: the file size is incorrect (because it
is unknown before the content is generated), and seeking in such
files (as required by partial writes) is unlikely to work
correctly.

With this patch, Go's `io.Copy` gracefully falls back to a normal
read/write file copy.

I'm not 100% sure which stable tree this should go in, I'd say
at least >=5.3 since this is what introduced support for
cross-filesystem copy_file_range (and where most users are
somewhat likely to hit this issue). But let's discuss the patch
series first.

[1] http://issuetracker.google.com/issues/178332739
[2] https://lkml.org/lkml/2021/1/25/64
[3] https://lkml.org/lkml/2021/1/26/1736


Nicolas Boichat (6):
  fs: Add flag to file_system_type to indicate content is generated
  proc: Add FS_GENERATED_CONTENT to filesystem flags
  sysfs: Add FS_GENERATED_CONTENT to filesystem flags
  debugfs: Add FS_GENERATED_CONTENT to filesystem flags
  tracefs: Add FS_GENERATED_CONTENT to filesystem flags
  vfs: Disallow copy_file_range on generated file systems

 fs/debugfs/inode.c | 1 +
 fs/proc/root.c     | 2 +-
 fs/read_write.c    | 3 +++
 fs/sysfs/mount.c   | 2 +-
 fs/tracefs/inode.c | 1 +
 include/linux/fs.h | 1 +
 6 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Nicolas Boichat]

Filesystems such as procfs and sysfs generate their content at
runtime. This implies the file sizes do not usually match the
amount of data that can be read from the file, and that seeking
may not work as intended.

This will be useful to disallow copy_file_range with input files
from such filesystems.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
I first thought of adding a new field to struct file_operations,
but that doesn't quite scale as every single file creation
operation would need to be modified.

 include/linux/fs.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3482146b11b0..5bd58b928e94 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2335,6 +2335,7 @@ struct file_system_type {
 #define FS_ALLOW_IDMAP         32      /* FS has been updated to handle vfs idmappings. */
 #define FS_THP_SUPPORT		8192	/* Remove once all fs converted */
 #define FS_RENAME_DOES_D_MOVE	32768	/* FS will handle d_move() during rename() internally. */
+#define FS_GENERATED_CONTENT	65536	/* FS contains generated content */
 	int (*init_fs_context)(struct fs_context *);
 	const struct fs_parameter_spec *parameters;
 	struct dentry *(*mount) (struct file_system_type *, int,
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 2/6] proc: Add FS_GENERATED_CONTENT to filesystem flags

[Nicolas Boichat]

procfs content is generated at runtime.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

 fs/proc/root.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/root.c b/fs/proc/root.c
index c7e3b1350ef8..7ed715a0f807 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -282,7 +282,7 @@ static struct file_system_type proc_fs_type = {
 	.init_fs_context	= proc_init_fs_context,
 	.parameters		= proc_fs_parameters,
 	.kill_sb		= proc_kill_sb,
-	.fs_flags		= FS_USERNS_MOUNT | FS_DISALLOW_NOTIFY_PERM,
+	.fs_flags		= FS_USERNS_MOUNT | FS_DISALLOW_NOTIFY_PERM | FS_GENERATED_CONTENT,
 };
 
 void __init proc_root_init(void)
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 3/6] sysfs: Add FS_GENERATED_CONTENT to filesystem flags

[Nicolas Boichat]

sysfs content is generated at runtime.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

 fs/sysfs/mount.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index e747c135c1d1..7e367ae5edc1 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -91,7 +91,7 @@ static struct file_system_type sysfs_fs_type = {
 	.name			= "sysfs",
 	.init_fs_context	= sysfs_init_fs_context,
 	.kill_sb		= sysfs_kill_sb,
-	.fs_flags		= FS_USERNS_MOUNT,
+	.fs_flags		= FS_USERNS_MOUNT | FS_GENERATED_CONTENT,
 };
 
 int __init sysfs_init(void)
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 4/6] debugfs: Add FS_GENERATED_CONTENT to filesystem flags

[Nicolas Boichat]

debugfs content is generated at runtime.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

 fs/debugfs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c35249497b9b..2bbc5e6d3041 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -279,6 +279,7 @@ static struct file_system_type debug_fs_type = {
 	.name =		"debugfs",
 	.mount =	debug_mount,
 	.kill_sb =	kill_litter_super,
+	.fs_flags =	FS_GENERATED_CONTENT,
 };
 MODULE_ALIAS_FS("debugfs");
 
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 5/6] tracefs: Add FS_GENERATED_CONTENT to filesystem flags

[Nicolas Boichat]

tracefs content is generated at runtime.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

 fs/tracefs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 4b83cbded559..89980312c7a3 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -308,6 +308,7 @@ static struct file_system_type trace_fs_type = {
 	.name =		"tracefs",
 	.mount =	trace_mount,
 	.kill_sb =	kill_litter_super,
+	.fs_flags =	FS_GENERATED_CONTENT,
 };
 MODULE_ALIAS_FS("tracefs");
 
-- 
2.30.0.478.g8a0d178c01-goog

[PATCH 6/6] vfs: Disallow copy_file_range on generated file systems

[Nicolas Boichat]

copy_file_range (which calls generic_copy_file_checks) uses the
inode file size to adjust the copy count parameter. This breaks
with special filesystems like procfs/sysfs/debugfs/tracefs, where
the file size appears to be zero, but content is actually returned
when a read operation is performed. Other issues would also
happen on partial writes, as the function would attempt to seek
in the input file.

Use the newly introduced FS_GENERATED_CONTENT filesystem flag
to return -EOPNOTSUPP: applications can then retry with a more
usual read/write based file copy (the fallback code is usually
already present to handle older kernels).

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---

 fs/read_write.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/read_write.c b/fs/read_write.c
index 0029ff2b0ca8..80322e89fb0a 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 	if (flags != 0)
 		return -EINVAL;
 
+	if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT)
+		return -EOPNOTSUPP;
+
 	ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
 				       flags);
 	if (unlikely(ret))
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems

[Darrick J. Wong]

On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote:
> copy_file_range (which calls generic_copy_file_checks) uses the
> inode file size to adjust the copy count parameter. This breaks
> with special filesystems like procfs/sysfs/debugfs/tracefs, where
> the file size appears to be zero, but content is actually returned
> when a read operation is performed. Other issues would also
> happen on partial writes, as the function would attempt to seek
> in the input file.
> 
> Use the newly introduced FS_GENERATED_CONTENT filesystem flag
> to return -EOPNOTSUPP: applications can then retry with a more
> usual read/write based file copy (the fallback code is usually
> already present to handle older kernels).
> 
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
> 
>  fs/read_write.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 0029ff2b0ca8..80322e89fb0a 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  	if (flags != 0)
>  		return -EINVAL;
>  
> +	if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT)
> +		return -EOPNOTSUPP;

Why not declare a dummy copy_file_range_nop function that returns
EOPNOTSUPP and point all of these filesystems at it?

(Or, I guess in these days where function pointers are the enemy,
create a #define that is a cast of 0x1, and fix do_copy_file_range to
return EOPNOTSUPP if it sees that?)

--D

> +
>  	ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
>  				       flags);
>  	if (unlikely(ret))
> -- 
> 2.30.0.478.g8a0d178c01-goog
> 

Re: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems

[Darrick J. Wong]

On Thu, Feb 11, 2021 at 08:53:47PM -0800, Darrick J. Wong wrote:
> On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote:
> > copy_file_range (which calls generic_copy_file_checks) uses the
> > inode file size to adjust the copy count parameter. This breaks
> > with special filesystems like procfs/sysfs/debugfs/tracefs, where
> > the file size appears to be zero, but content is actually returned
> > when a read operation is performed. Other issues would also
> > happen on partial writes, as the function would attempt to seek
> > in the input file.
> > 
> > Use the newly introduced FS_GENERATED_CONTENT filesystem flag
> > to return -EOPNOTSUPP: applications can then retry with a more
> > usual read/write based file copy (the fallback code is usually
> > already present to handle older kernels).
> > 
> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > ---
> > 
> >  fs/read_write.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/fs/read_write.c b/fs/read_write.c
> > index 0029ff2b0ca8..80322e89fb0a 100644
> > --- a/fs/read_write.c
> > +++ b/fs/read_write.c
> > @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> >  	if (flags != 0)
> >  		return -EINVAL;
> >  
> > +	if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT)
> > +		return -EOPNOTSUPP;
> 
> Why not declare a dummy copy_file_range_nop function that returns
> EOPNOTSUPP and point all of these filesystems at it?
> 
> (Or, I guess in these days where function pointers are the enemy,
> create a #define that is a cast of 0x1, and fix do_copy_file_range to
> return EOPNOTSUPP if it sees that?)

Oh, I see, because that doesn't help if the source file is procfs and
the dest file is (say) xfs, because the generic version will try to do
splice magic and *poof*.

I guess the other nit thatI can think of at this late hour is ... what
about the other virtual filesystems like configfs and whatnot?  Should
we have a way to flag them as "this can't be the source of a CFR
request" as well?

Or is it just trace/debug/proc/sysfs that have these "zero size but
readable" speshul behaviors?

--D

> 
> --D
> 
> > +
> >  	ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
> >  				       flags);
> >  	if (unlikely(ret))
> > -- 
> > 2.30.0.478.g8a0d178c01-goog
> > 

Re: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems

[Nicolas Boichat]

On Fri, Feb 12, 2021 at 12:59 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Thu, Feb 11, 2021 at 08:53:47PM -0800, Darrick J. Wong wrote:
> > On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote:
> > > copy_file_range (which calls generic_copy_file_checks) uses the
> > > inode file size to adjust the copy count parameter. This breaks
> > > with special filesystems like procfs/sysfs/debugfs/tracefs, where
> > > the file size appears to be zero, but content is actually returned
> > > when a read operation is performed. Other issues would also
> > > happen on partial writes, as the function would attempt to seek
> > > in the input file.
> > >
> > > Use the newly introduced FS_GENERATED_CONTENT filesystem flag
> > > to return -EOPNOTSUPP: applications can then retry with a more
> > > usual read/write based file copy (the fallback code is usually
> > > already present to handle older kernels).
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > > ---
> > >
> > >  fs/read_write.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/fs/read_write.c b/fs/read_write.c
> > > index 0029ff2b0ca8..80322e89fb0a 100644
> > > --- a/fs/read_write.c
> > > +++ b/fs/read_write.c
> > > @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> > >     if (flags != 0)
> > >             return -EINVAL;
> > >
> > > +   if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT)
> > > +           return -EOPNOTSUPP;
> >
> > Why not declare a dummy copy_file_range_nop function that returns
> > EOPNOTSUPP and point all of these filesystems at it?
> >
> > (Or, I guess in these days where function pointers are the enemy,
> > create a #define that is a cast of 0x1, and fix do_copy_file_range to
> > return EOPNOTSUPP if it sees that?)

I was pondering abusing ERR_PTR(-EOPNOTSUPP) for this purpose ,-P

>
> Oh, I see, because that doesn't help if the source file is procfs and
> the dest file is (say) xfs, because the generic version will try to do
> splice magic and *poof*.

Yep. I mean, we could still add a check if the
file_in->f_op->copy_file_range == copy_file_range_nop in
do_copy_file_range...
But then we'd need to sprinkle .copy_file_range = copy_file_range_nop
in many many places (~700 as a lower bound[1]), since the file
operation structure is defined at the file level, not at the FS level,
and people are likely to forget...

[1]
$ git grep "struct file_operations.*=" | grep debug | wc -l
631
$ git grep "struct file_operations.*=" | grep trace | wc -l
84

>
> I guess the other nit thatI can think of at this late hour is ... what
> about the other virtual filesystems like configfs and whatnot?  Should
> we have a way to flag them as "this can't be the source of a CFR
> request" as well?
>
> Or is it just trace/debug/proc/sysfs that have these "zero size but
> readable" speshul behaviors?

I did try to audit the other filesystems. The ones I spotted:
 - devpts should be fine (only device nodes in there)
 - I think pstore doesn't need the flag as it's RAM-backed and persistent.

But yes, I missed configfs, thanks for catching that. I think we need
to add the flag for that one (looks like the sizes are all 4K).

>
> --D
>
> >
> > --D
> >
> > > +
> > >     ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
> > >                                    flags);
> > >     if (unlikely(ret))
> > > --
> > > 2.30.0.478.g8a0d178c01-goog
> > >

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
> 
> This will be useful to disallow copy_file_range with input files
> from such filesystems.
> 
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
> I first thought of adding a new field to struct file_operations,
> but that doesn't quite scale as every single file creation
> operation would need to be modified.

Even so, you missed a load of filesystems in the kernel with this patch
series, what makes the ones you did mark here different from the
"internal" filesystems that you did not?

This feels wrong, why is userspace suddenly breaking?  What changed in
the kernel that caused this?  Procfs has been around for a _very_ long
time :)

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Amir Goldstein]

On Fri, Feb 12, 2021 at 6:47 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
>
> This will be useful to disallow copy_file_range with input files
> from such filesystems.
>
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> ---
> I first thought of adding a new field to struct file_operations,
> but that doesn't quite scale as every single file creation
> operation would need to be modified.
>
>  include/linux/fs.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3482146b11b0..5bd58b928e94 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2335,6 +2335,7 @@ struct file_system_type {
>  #define FS_ALLOW_IDMAP         32      /* FS has been updated to handle vfs idmappings. */
>  #define FS_THP_SUPPORT         8192    /* Remove once all fs converted */
>  #define FS_RENAME_DOES_D_MOVE  32768   /* FS will handle d_move() during rename() internally. */
> +#define FS_GENERATED_CONTENT   65536   /* FS contains generated content */

Can you please make the flag name a little less arbitrary.

Either something that conveys the facts as they are (e.g. "zero size
but readable")
or anything that you think describes best the special behavior that follows from
observing this flag.

The alternative is for the flag name to express what you want
(e.g. "don't copy file range") like FS_DISALLOW_NOTIFY_PERM.

Also, I wonder. A great deal of the files you target are opened with seq_open()
(I didn't audit all of them). Maybe it's worth setting an FMODE flag
in seq_open()
and some of it's relatives to express the quality of the file instead
of flagging
the filesystem? Maybe we can do both to cover more cases.

Thanks,
Amir.

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Nicolas Boichat]

On Fri, Feb 12, 2021 at 3:46 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > Filesystems such as procfs and sysfs generate their content at
> > runtime. This implies the file sizes do not usually match the
> > amount of data that can be read from the file, and that seeking
> > may not work as intended.
> >
> > This will be useful to disallow copy_file_range with input files
> > from such filesystems.
> >
> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > ---
> > I first thought of adding a new field to struct file_operations,
> > but that doesn't quite scale as every single file creation
> > operation would need to be modified.
>
> Even so, you missed a load of filesystems in the kernel with this patch
> series, what makes the ones you did mark here different from the
> "internal" filesystems that you did not?

Which ones did I miss? (apart from configfs, see the conversation on
patch 6/6). Anyway, hopefully auditing all filesystems is an order of
magnitude easier task, and easier to maintain in the longer run ,-)

> This feels wrong, why is userspace suddenly breaking?  What changed in
> the kernel that caused this?  Procfs has been around for a _very_ long
> time :)

Some of this is covered in the cover letter 0/6. To expand a bit:
copy_file_range has only supported cross-filesystem copies since 5.3
[1], before that the kernel would return EXDEV and userspace
application would fall back to a read/write based copy. After 5.3,
copy_file_range copies no data as it thinks the input file is empty.

[1] I think it makes little sense to try to use copy_file_range
between 2 files in /proc, but technically, I think that has been
broken since copy_file_range fallback to do_splice_direct was
introduced (eac70053a141 ("vfs: Add vfs_copy_file_range() support for
pagecache copies", ~4.4).

>
> thanks,
>
> greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Amir Goldstein]

On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > Filesystems such as procfs and sysfs generate their content at
> > runtime. This implies the file sizes do not usually match the
> > amount of data that can be read from the file, and that seeking
> > may not work as intended.
> >
> > This will be useful to disallow copy_file_range with input files
> > from such filesystems.
> >
> > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > ---
> > I first thought of adding a new field to struct file_operations,
> > but that doesn't quite scale as every single file creation
> > operation would need to be modified.
>
> Even so, you missed a load of filesystems in the kernel with this patch
> series, what makes the ones you did mark here different from the
> "internal" filesystems that you did not?
>
> This feels wrong, why is userspace suddenly breaking?  What changed in
> the kernel that caused this?  Procfs has been around for a _very_ long
> time :)

That would be because of (v5.3):

5dae222a5ff0 vfs: allow copy_file_range to copy across devices

The intention of this change (series) was to allow server side copy
for nfs and cifs via copy_file_range().
This is mostly work by Dave Chinner that I picked up following requests
from the NFS folks.

But the above change also includes this generic change:

-       /* this could be relaxed once a method supports cross-fs copies */
-       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
-               return -EXDEV;
-

The change of behavior was documented in the commit message.
It was also documented in:

88e75e2c5 copy_file_range.2: Kernel v5.3 updates

I think our rationale for the generic change was:
"Why not? What could go wrong? (TM)"
I am not sure if any workload really gained something from this
kernel cross-fs CFR.

In retrospect, I think it would have been safer to allow cross-fs CFR
only to the filesystems that implement ->{copy,remap}_file_range()...

Our option now are:
- Restore the cross-fs restriction into generic_copy_file_range()
- Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does

Preference anyone?

Thanks,
Amir.

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 04:20:17PM +0800, Nicolas Boichat wrote:
> On Fri, Feb 12, 2021 at 3:46 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > > Filesystems such as procfs and sysfs generate their content at
> > > runtime. This implies the file sizes do not usually match the
> > > amount of data that can be read from the file, and that seeking
> > > may not work as intended.
> > >
> > > This will be useful to disallow copy_file_range with input files
> > > from such filesystems.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > > ---
> > > I first thought of adding a new field to struct file_operations,
> > > but that doesn't quite scale as every single file creation
> > > operation would need to be modified.
> >
> > Even so, you missed a load of filesystems in the kernel with this patch
> > series, what makes the ones you did mark here different from the
> > "internal" filesystems that you did not?
> 
> Which ones did I miss? (apart from configfs, see the conversation on
> patch 6/6). Anyway, hopefully auditing all filesystems is an order of
> magnitude easier task, and easier to maintain in the longer run ,-)

Are you going to be the one to add this to each new filesystem that is
added to the kernel?

I see filesystems in drivers/char/mem.c and
drivers/infiniband/hw/qib/qib_fs.c and drivers/misc/ibmasm/ibmasmfs.c
and loads of other driver-specific filesystems.  Do all of those "just
work" somehow?

> > This feels wrong, why is userspace suddenly breaking?  What changed in
> > the kernel that caused this?  Procfs has been around for a _very_ long
> > time :)
> 
> Some of this is covered in the cover letter 0/6. To expand a bit:
> copy_file_range has only supported cross-filesystem copies since 5.3
> [1], before that the kernel would return EXDEV and userspace
> application would fall back to a read/write based copy. After 5.3,
> copy_file_range copies no data as it thinks the input file is empty.

So older kernels work fine with this system call on procfs, but newer
ones do not?  If so, that's a regression that should be fixed in the
original area, but should not require a new filesystem flag for every
individual one out there.  That way lies madness and constant auditing
that I do not see anyone signing up for for the next 20 years, right?

> [1] I think it makes little sense to try to use copy_file_range
> between 2 files in /proc, but technically, I think that has been
> broken since copy_file_range fallback to do_splice_direct was
> introduced (eac70053a141 ("vfs: Add vfs_copy_file_range() support for
> pagecache copies", ~4.4).

Why are people trying to use copy_file_range on simple /proc and /sys
files in the first place?  They can not seek (well most can not), so
that feels like a "oh look, a new syscall, let's use it everywhere!"
problem that userspace should not do.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > > Filesystems such as procfs and sysfs generate their content at
> > > runtime. This implies the file sizes do not usually match the
> > > amount of data that can be read from the file, and that seeking
> > > may not work as intended.
> > >
> > > This will be useful to disallow copy_file_range with input files
> > > from such filesystems.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > > ---
> > > I first thought of adding a new field to struct file_operations,
> > > but that doesn't quite scale as every single file creation
> > > operation would need to be modified.
> >
> > Even so, you missed a load of filesystems in the kernel with this patch
> > series, what makes the ones you did mark here different from the
> > "internal" filesystems that you did not?
> >
> > This feels wrong, why is userspace suddenly breaking?  What changed in
> > the kernel that caused this?  Procfs has been around for a _very_ long
> > time :)
> 
> That would be because of (v5.3):
> 
> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> 
> The intention of this change (series) was to allow server side copy
> for nfs and cifs via copy_file_range().
> This is mostly work by Dave Chinner that I picked up following requests
> from the NFS folks.
> 
> But the above change also includes this generic change:
> 
> -       /* this could be relaxed once a method supports cross-fs copies */
> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> -               return -EXDEV;
> -
> 
> The change of behavior was documented in the commit message.
> It was also documented in:
> 
> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
> 
> I think our rationale for the generic change was:
> "Why not? What could go wrong? (TM)"
> I am not sure if any workload really gained something from this
> kernel cross-fs CFR.

Why not put that check back?

> In retrospect, I think it would have been safer to allow cross-fs CFR
> only to the filesystems that implement ->{copy,remap}_file_range()...

Why not make this change?  That seems easier and should fix this for
everyone, right?

> Our option now are:
> - Restore the cross-fs restriction into generic_copy_file_range()

Yes.

> - Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does

No.  That way lies constant auditing and someone being "vigilant" for
the next 30+ years.  Which will not happen.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
>> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>> >
>> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
>> > > Filesystems such as procfs and sysfs generate their content at
>> > > runtime. This implies the file sizes do not usually match the
>> > > amount of data that can be read from the file, and that seeking
>> > > may not work as intended.
>> > >
>> > > This will be useful to disallow copy_file_range with input files
>> > > from such filesystems.
>> > >
>> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>> > > ---
>> > > I first thought of adding a new field to struct file_operations,
>> > > but that doesn't quite scale as every single file creation
>> > > operation would need to be modified.
>> >
>> > Even so, you missed a load of filesystems in the kernel with this patch
>> > series, what makes the ones you did mark here different from the
>> > "internal" filesystems that you did not?
>> >
>> > This feels wrong, why is userspace suddenly breaking?  What changed in
>> > the kernel that caused this?  Procfs has been around for a _very_ long
>> > time :)
>> 
>> That would be because of (v5.3):
>> 
>> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
>> 
>> The intention of this change (series) was to allow server side copy
>> for nfs and cifs via copy_file_range().
>> This is mostly work by Dave Chinner that I picked up following requests
>> from the NFS folks.
>> 
>> But the above change also includes this generic change:
>> 
>> -       /* this could be relaxed once a method supports cross-fs copies */
>> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> -               return -EXDEV;
>> -
>> 
>> The change of behavior was documented in the commit message.
>> It was also documented in:
>> 
>> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
>> 
>> I think our rationale for the generic change was:
>> "Why not? What could go wrong? (TM)"
>> I am not sure if any workload really gained something from this
>> kernel cross-fs CFR.
>
> Why not put that check back?
>
>> In retrospect, I think it would have been safer to allow cross-fs CFR
>> only to the filesystems that implement ->{copy,remap}_file_range()...
>
> Why not make this change?  That seems easier and should fix this for
> everyone, right?
>
>> Our option now are:
>> - Restore the cross-fs restriction into generic_copy_file_range()
>
> Yes.
>

Restoring this restriction will actually change the current cephfs CFR
behaviour.  Since that commit we have allowed doing remote copies between
different filesystems within the same ceph cluster.  See commit
6fd4e6348352 ("ceph: allow object copies across different filesystems in
the same cluster").

Although I'm not aware of any current users for this scenario, the
performance impact can actually be huge as it's the difference between
asking the OSDs for copying a file and doing a full read+write on the
client side.

Cheers,
-- 
Luis


>> - Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does
>
> No.  That way lies constant auditing and someone being "vigilant" for
> the next 30+ years.  Which will not happen.
>
> thanks,
>
> greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 12:05:14PM +0000, Luis Henriques wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >
> >> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> >> > > Filesystems such as procfs and sysfs generate their content at
> >> > > runtime. This implies the file sizes do not usually match the
> >> > > amount of data that can be read from the file, and that seeking
> >> > > may not work as intended.
> >> > >
> >> > > This will be useful to disallow copy_file_range with input files
> >> > > from such filesystems.
> >> > >
> >> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> >> > > ---
> >> > > I first thought of adding a new field to struct file_operations,
> >> > > but that doesn't quite scale as every single file creation
> >> > > operation would need to be modified.
> >> >
> >> > Even so, you missed a load of filesystems in the kernel with this patch
> >> > series, what makes the ones you did mark here different from the
> >> > "internal" filesystems that you did not?
> >> >
> >> > This feels wrong, why is userspace suddenly breaking?  What changed in
> >> > the kernel that caused this?  Procfs has been around for a _very_ long
> >> > time :)
> >> 
> >> That would be because of (v5.3):
> >> 
> >> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> >> 
> >> The intention of this change (series) was to allow server side copy
> >> for nfs and cifs via copy_file_range().
> >> This is mostly work by Dave Chinner that I picked up following requests
> >> from the NFS folks.
> >> 
> >> But the above change also includes this generic change:
> >> 
> >> -       /* this could be relaxed once a method supports cross-fs copies */
> >> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >> -               return -EXDEV;
> >> -
> >> 
> >> The change of behavior was documented in the commit message.
> >> It was also documented in:
> >> 
> >> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
> >> 
> >> I think our rationale for the generic change was:
> >> "Why not? What could go wrong? (TM)"
> >> I am not sure if any workload really gained something from this
> >> kernel cross-fs CFR.
> >
> > Why not put that check back?
> >
> >> In retrospect, I think it would have been safer to allow cross-fs CFR
> >> only to the filesystems that implement ->{copy,remap}_file_range()...
> >
> > Why not make this change?  That seems easier and should fix this for
> > everyone, right?
> >
> >> Our option now are:
> >> - Restore the cross-fs restriction into generic_copy_file_range()
> >
> > Yes.
> >
> 
> Restoring this restriction will actually change the current cephfs CFR
> behaviour.  Since that commit we have allowed doing remote copies between
> different filesystems within the same ceph cluster.  See commit
> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
> the same cluster").
> 
> Although I'm not aware of any current users for this scenario, the
> performance impact can actually be huge as it's the difference between
> asking the OSDs for copying a file and doing a full read+write on the
> client side.

Regression in performance is ok if it fixes a regression for things that
used to work just fine in the past :)

First rule, make it work.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Fri, Feb 12, 2021 at 12:05:14PM +0000, Luis Henriques wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>> 
>> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
>> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>> >> >
>> >> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
>> >> > > Filesystems such as procfs and sysfs generate their content at
>> >> > > runtime. This implies the file sizes do not usually match the
>> >> > > amount of data that can be read from the file, and that seeking
>> >> > > may not work as intended.
>> >> > >
>> >> > > This will be useful to disallow copy_file_range with input files
>> >> > > from such filesystems.
>> >> > >
>> >> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>> >> > > ---
>> >> > > I first thought of adding a new field to struct file_operations,
>> >> > > but that doesn't quite scale as every single file creation
>> >> > > operation would need to be modified.
>> >> >
>> >> > Even so, you missed a load of filesystems in the kernel with this patch
>> >> > series, what makes the ones you did mark here different from the
>> >> > "internal" filesystems that you did not?
>> >> >
>> >> > This feels wrong, why is userspace suddenly breaking?  What changed in
>> >> > the kernel that caused this?  Procfs has been around for a _very_ long
>> >> > time :)
>> >> 
>> >> That would be because of (v5.3):
>> >> 
>> >> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
>> >> 
>> >> The intention of this change (series) was to allow server side copy
>> >> for nfs and cifs via copy_file_range().
>> >> This is mostly work by Dave Chinner that I picked up following requests
>> >> from the NFS folks.
>> >> 
>> >> But the above change also includes this generic change:
>> >> 
>> >> -       /* this could be relaxed once a method supports cross-fs copies */
>> >> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> >> -               return -EXDEV;
>> >> -
>> >> 
>> >> The change of behavior was documented in the commit message.
>> >> It was also documented in:
>> >> 
>> >> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
>> >> 
>> >> I think our rationale for the generic change was:
>> >> "Why not? What could go wrong? (TM)"
>> >> I am not sure if any workload really gained something from this
>> >> kernel cross-fs CFR.
>> >
>> > Why not put that check back?
>> >
>> >> In retrospect, I think it would have been safer to allow cross-fs CFR
>> >> only to the filesystems that implement ->{copy,remap}_file_range()...
>> >
>> > Why not make this change?  That seems easier and should fix this for
>> > everyone, right?
>> >
>> >> Our option now are:
>> >> - Restore the cross-fs restriction into generic_copy_file_range()
>> >
>> > Yes.
>> >
>> 
>> Restoring this restriction will actually change the current cephfs CFR
>> behaviour.  Since that commit we have allowed doing remote copies between
>> different filesystems within the same ceph cluster.  See commit
>> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
>> the same cluster").
>> 
>> Although I'm not aware of any current users for this scenario, the
>> performance impact can actually be huge as it's the difference between
>> asking the OSDs for copying a file and doing a full read+write on the
>> client side.
>
> Regression in performance is ok if it fixes a regression for things that
> used to work just fine in the past :)
>
> First rule, make it work.

Sure, I just wanted to point out that *maybe* there are other options than
simply reverting that commit :-)

Something like the patch below (completely untested!) should revert to the
old behaviour in filesystems that don't implement the CFR syscall.

Cheers,
-- 
Luis

diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..bf5dccc43cc9 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
 						       file_out, pos_out,
 						       len, flags);
 
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
+	if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+		return -EXDEV;
+	else
+		generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
+					flags);
 }
 
 /*

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 12:41:48PM +0000, Luis Henriques wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
> 
> > On Fri, Feb 12, 2021 at 12:05:14PM +0000, Luis Henriques wrote:
> >> Greg KH <gregkh@linuxfoundation.org> writes:
> >> 
> >> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> >> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> >
> >> >> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> >> >> > > Filesystems such as procfs and sysfs generate their content at
> >> >> > > runtime. This implies the file sizes do not usually match the
> >> >> > > amount of data that can be read from the file, and that seeking
> >> >> > > may not work as intended.
> >> >> > >
> >> >> > > This will be useful to disallow copy_file_range with input files
> >> >> > > from such filesystems.
> >> >> > >
> >> >> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> >> >> > > ---
> >> >> > > I first thought of adding a new field to struct file_operations,
> >> >> > > but that doesn't quite scale as every single file creation
> >> >> > > operation would need to be modified.
> >> >> >
> >> >> > Even so, you missed a load of filesystems in the kernel with this patch
> >> >> > series, what makes the ones you did mark here different from the
> >> >> > "internal" filesystems that you did not?
> >> >> >
> >> >> > This feels wrong, why is userspace suddenly breaking?  What changed in
> >> >> > the kernel that caused this?  Procfs has been around for a _very_ long
> >> >> > time :)
> >> >> 
> >> >> That would be because of (v5.3):
> >> >> 
> >> >> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> >> >> 
> >> >> The intention of this change (series) was to allow server side copy
> >> >> for nfs and cifs via copy_file_range().
> >> >> This is mostly work by Dave Chinner that I picked up following requests
> >> >> from the NFS folks.
> >> >> 
> >> >> But the above change also includes this generic change:
> >> >> 
> >> >> -       /* this could be relaxed once a method supports cross-fs copies */
> >> >> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >> >> -               return -EXDEV;
> >> >> -
> >> >> 
> >> >> The change of behavior was documented in the commit message.
> >> >> It was also documented in:
> >> >> 
> >> >> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
> >> >> 
> >> >> I think our rationale for the generic change was:
> >> >> "Why not? What could go wrong? (TM)"
> >> >> I am not sure if any workload really gained something from this
> >> >> kernel cross-fs CFR.
> >> >
> >> > Why not put that check back?
> >> >
> >> >> In retrospect, I think it would have been safer to allow cross-fs CFR
> >> >> only to the filesystems that implement ->{copy,remap}_file_range()...
> >> >
> >> > Why not make this change?  That seems easier and should fix this for
> >> > everyone, right?
> >> >
> >> >> Our option now are:
> >> >> - Restore the cross-fs restriction into generic_copy_file_range()
> >> >
> >> > Yes.
> >> >
> >> 
> >> Restoring this restriction will actually change the current cephfs CFR
> >> behaviour.  Since that commit we have allowed doing remote copies between
> >> different filesystems within the same ceph cluster.  See commit
> >> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
> >> the same cluster").
> >> 
> >> Although I'm not aware of any current users for this scenario, the
> >> performance impact can actually be huge as it's the difference between
> >> asking the OSDs for copying a file and doing a full read+write on the
> >> client side.
> >
> > Regression in performance is ok if it fixes a regression for things that
> > used to work just fine in the past :)
> >
> > First rule, make it work.
> 
> Sure, I just wanted to point out that *maybe* there are other options than
> simply reverting that commit :-)
> 
> Something like the patch below (completely untested!) should revert to the
> old behaviour in filesystems that don't implement the CFR syscall.
> 
> Cheers,
> -- 
> Luis
> 
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..bf5dccc43cc9 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>  						       file_out, pos_out,
>  						       len, flags);
>  
> -	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -				       flags);
> +	if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +		return -EXDEV;
> +	else
> +		generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> +					flags);
>  }
>  
>  /*

That would make much more sense to me.

Re: [PATCH 5/6] tracefs: Add FS_GENERATED_CONTENT to filesystem flags

[Steven Rostedt]

On Fri, 12 Feb 2021 12:44:04 +0800
Nicolas Boichat <drinkcat@chromium.org> wrote:

> tracefs content is generated at runtime.
> 
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>

Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

-- Steve

> ---
> 
>  fs/tracefs/inode.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index 4b83cbded559..89980312c7a3 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -308,6 +308,7 @@ static struct file_system_type trace_fs_type = {
>  	.name =		"tracefs",
>  	.mount =	trace_mount,
>  	.kill_sb =	kill_litter_super,
> +	.fs_flags =	FS_GENERATED_CONTENT,
>  };
>  MODULE_ALIAS_FS("tracefs");
>  

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Fri, Feb 12, 2021 at 12:41:48PM +0000, Luis Henriques wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
...
>> >> >> Our option now are:
>> >> >> - Restore the cross-fs restriction into generic_copy_file_range()
>> >> >
>> >> > Yes.
>> >> >
>> >> 
>> >> Restoring this restriction will actually change the current cephfs CFR
>> >> behaviour.  Since that commit we have allowed doing remote copies between
>> >> different filesystems within the same ceph cluster.  See commit
>> >> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
>> >> the same cluster").
>> >> 
>> >> Although I'm not aware of any current users for this scenario, the
>> >> performance impact can actually be huge as it's the difference between
>> >> asking the OSDs for copying a file and doing a full read+write on the
>> >> client side.
>> >
>> > Regression in performance is ok if it fixes a regression for things that
>> > used to work just fine in the past :)
>> >
>> > First rule, make it work.
>> 
>> Sure, I just wanted to point out that *maybe* there are other options than
>> simply reverting that commit :-)
>> 
>> Something like the patch below (completely untested!) should revert to the
>> old behaviour in filesystems that don't implement the CFR syscall.
>> 
>> Cheers,
>> -- 
>> Luis
>> 
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..bf5dccc43cc9 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>>  						       file_out, pos_out,
>>  						       len, flags);
>>  
>> -	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> -				       flags);
>> +	if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> +		return -EXDEV;
>> +	else
>> +		generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> +					flags);
>>  }
>>  
>>  /*
>
> That would make much more sense to me.

Great.  I can send a proper patch with changelog, if this is the really
what we want.  But I would rather hear from others first.  I guess that at
least the NFS devs have something to say here.

Cheers,
-- 
Luis

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Ian Lance Taylor]

On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Why are people trying to use copy_file_range on simple /proc and /sys
> files in the first place?  They can not seek (well most can not), so
> that feels like a "oh look, a new syscall, let's use it everywhere!"
> problem that userspace should not do.

This may have been covered elsewhere, but it's not that people are
saying "let's use copy_file_range on files in /proc."  It's that the
Go language standard library provides an interface to operating system
files.  When Go code uses the standard library function io.Copy to
copy the contents of one open file to another open file, then on Linux
kernels 5.3 and greater the Go standard library will use the
copy_file_range system call.  That seems to be exactly what
copy_file_range is intended for.  Unfortunately it appears that when
people writing Go code open a file in /proc and use io.Copy the
contents to another open file, copy_file_range does nothing and
reports success.  There isn't anything on the copy_file_range man page
explaining this limitation, and there isn't any documented way to know
that the Go standard library should not use copy_file_range on certain
files.

So ideally the kernel will report EOPNOTSUPP or EINVAL when using
copy_file_range on a file in /proc or some other file system that
fails (and, minor side note, the copy_file_range man page should
document that it can return EOPNOTSUPP or EINVAL in some cases, which
does already happen on at least some kernel versions using at least
some file systems).  Or, less ideally, there will be some documented
way that the Go standard library can determine that copy_file_range
will fail before trying to use it.  If neither of those can be done,
then I think the only option is for the Go standard library to never
use copy_file_range, as even though it will almost always work and
work well, in some unpredictable number of cases it will fail
silently.

Thanks.

Ian

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > Why are people trying to use copy_file_range on simple /proc and /sys
> > files in the first place?  They can not seek (well most can not), so
> > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > problem that userspace should not do.
> 
> This may have been covered elsewhere, but it's not that people are
> saying "let's use copy_file_range on files in /proc."  It's that the
> Go language standard library provides an interface to operating system
> files.  When Go code uses the standard library function io.Copy to
> copy the contents of one open file to another open file, then on Linux
> kernels 5.3 and greater the Go standard library will use the
> copy_file_range system call.  That seems to be exactly what
> copy_file_range is intended for.  Unfortunately it appears that when
> people writing Go code open a file in /proc and use io.Copy the
> contents to another open file, copy_file_range does nothing and
> reports success.  There isn't anything on the copy_file_range man page
> explaining this limitation, and there isn't any documented way to know
> that the Go standard library should not use copy_file_range on certain
> files.

But, is this a bug in the kernel in that the syscall being made is not
working properly, or a bug in that Go decided to do this for all types
of files not knowing that some types of files can not handle this?

If the kernel has always worked this way, I would say that Go is doing
the wrong thing here.  If the kernel used to work properly, and then
changed, then it's a regression on the kernel side.

So which is it?

> So ideally the kernel will report EOPNOTSUPP or EINVAL when using
> copy_file_range on a file in /proc or some other file system that
> fails (and, minor side note, the copy_file_range man page should
> document that it can return EOPNOTSUPP or EINVAL in some cases, which
> does already happen on at least some kernel versions using at least
> some file systems).

Documentation is good, but what the kernel does is the true "definition"
of what is going right or wrong here.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Ian Lance Taylor]

On Fri, Feb 12, 2021 at 7:45 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > files in the first place?  They can not seek (well most can not), so
> > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > problem that userspace should not do.
> >
> > This may have been covered elsewhere, but it's not that people are
> > saying "let's use copy_file_range on files in /proc."  It's that the
> > Go language standard library provides an interface to operating system
> > files.  When Go code uses the standard library function io.Copy to
> > copy the contents of one open file to another open file, then on Linux
> > kernels 5.3 and greater the Go standard library will use the
> > copy_file_range system call.  That seems to be exactly what
> > copy_file_range is intended for.  Unfortunately it appears that when
> > people writing Go code open a file in /proc and use io.Copy the
> > contents to another open file, copy_file_range does nothing and
> > reports success.  There isn't anything on the copy_file_range man page
> > explaining this limitation, and there isn't any documented way to know
> > that the Go standard library should not use copy_file_range on certain
> > files.
>
> But, is this a bug in the kernel in that the syscall being made is not
> working properly, or a bug in that Go decided to do this for all types
> of files not knowing that some types of files can not handle this?
>
> If the kernel has always worked this way, I would say that Go is doing
> the wrong thing here.  If the kernel used to work properly, and then
> changed, then it's a regression on the kernel side.
>
> So which is it?

I don't work on the kernel, so I can't tell you which it is.  You will
have to decide.

From my perspective, as a kernel user rather than a kernel developer,
a system call that silently fails for certain files and that provides
no way to determine either 1) ahead of time that the system call will
fail, or 2) after the call that the system call did fail, is a useless
system call.  I can never use that system call, because I don't know
whether or not it will work.  So as a kernel user I would say that you
should fix the system call to report failure, or document some way to
know whether the system call will fail, or you should remove the
system call.  But I'm not a kernel developer, I don't have all the
information, and it's obviously your call.

I'll note that to the best of my knowledge this failure started
happening with the 5.3 kernel, as before 5.3 the problematic calls
would report a failure (EXDEV).  Since 5.3 isn't all that old I
personally wouldn't say that the kernel "has always worked this way."
But I may be mistaken about this.


> > So ideally the kernel will report EOPNOTSUPP or EINVAL when using
> > copy_file_range on a file in /proc or some other file system that
> > fails (and, minor side note, the copy_file_range man page should
> > document that it can return EOPNOTSUPP or EINVAL in some cases, which
> > does already happen on at least some kernel versions using at least
> > some file systems).
>
> Documentation is good, but what the kernel does is the true "definition"
> of what is going right or wrong here.

Sure.  The documentation comment was just a side note.  I hope that we
can all agree that accurate man pages are better than inaccurate ones.

Ian

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Fri, Feb 12, 2021 at 07:59:04AM -0800, Ian Lance Taylor wrote:
> On Fri, Feb 12, 2021 at 7:45 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > files in the first place?  They can not seek (well most can not), so
> > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > problem that userspace should not do.
> > >
> > > This may have been covered elsewhere, but it's not that people are
> > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > Go language standard library provides an interface to operating system
> > > files.  When Go code uses the standard library function io.Copy to
> > > copy the contents of one open file to another open file, then on Linux
> > > kernels 5.3 and greater the Go standard library will use the
> > > copy_file_range system call.  That seems to be exactly what
> > > copy_file_range is intended for.  Unfortunately it appears that when
> > > people writing Go code open a file in /proc and use io.Copy the
> > > contents to another open file, copy_file_range does nothing and
> > > reports success.  There isn't anything on the copy_file_range man page
> > > explaining this limitation, and there isn't any documented way to know
> > > that the Go standard library should not use copy_file_range on certain
> > > files.
> >
> > But, is this a bug in the kernel in that the syscall being made is not
> > working properly, or a bug in that Go decided to do this for all types
> > of files not knowing that some types of files can not handle this?
> >
> > If the kernel has always worked this way, I would say that Go is doing
> > the wrong thing here.  If the kernel used to work properly, and then
> > changed, then it's a regression on the kernel side.
> >
> > So which is it?
> 
> I don't work on the kernel, so I can't tell you which it is.  You will
> have to decide.

As you have the userspace code, it should be easier for you to test this
on an older kernel.  I don't have your userspace code...

> From my perspective, as a kernel user rather than a kernel developer,
> a system call that silently fails for certain files and that provides
> no way to determine either 1) ahead of time that the system call will
> fail, or 2) after the call that the system call did fail, is a useless
> system call.

Great, then don't use copy_file_range() yet as it seems like it fits
that category at the moment :)

> I can never use that system call, because I don't know
> whether or not it will work.  So as a kernel user I would say that you
> should fix the system call to report failure, or document some way to
> know whether the system call will fail, or you should remove the
> system call.  But I'm not a kernel developer, I don't have all the
> information, and it's obviously your call.

That's up to the authors of that syscall, I don't know what they
intended this to be used for.  It feels like you are using this in a
very generic "all file i/o works for this" way, while that is not what
the authors of the syscall intended it for, as is evident by the
failures that older kernels would report for you.

> I'll note that to the best of my knowledge this failure started
> happening with the 5.3 kernel, as before 5.3 the problematic calls
> would report a failure (EXDEV).  Since 5.3 isn't all that old I
> personally wouldn't say that the kernel "has always worked this way."
> But I may be mistaken about this.

Testing would be good, as regressions are more serious than "it would be
nice if it would work like this instead!" type of issues.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Ian Lance Taylor]

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

On Fri, Feb 12, 2021 at 8:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Feb 12, 2021 at 07:59:04AM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 7:45 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > > files in the first place?  They can not seek (well most can not), so
> > > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > > problem that userspace should not do.
> > > >
> > > > This may have been covered elsewhere, but it's not that people are
> > > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > > Go language standard library provides an interface to operating system
> > > > files.  When Go code uses the standard library function io.Copy to
> > > > copy the contents of one open file to another open file, then on Linux
> > > > kernels 5.3 and greater the Go standard library will use the
> > > > copy_file_range system call.  That seems to be exactly what
> > > > copy_file_range is intended for.  Unfortunately it appears that when
> > > > people writing Go code open a file in /proc and use io.Copy the
> > > > contents to another open file, copy_file_range does nothing and
> > > > reports success.  There isn't anything on the copy_file_range man page
> > > > explaining this limitation, and there isn't any documented way to know
> > > > that the Go standard library should not use copy_file_range on certain
> > > > files.
> > >
> > > But, is this a bug in the kernel in that the syscall being made is not
> > > working properly, or a bug in that Go decided to do this for all types
> > > of files not knowing that some types of files can not handle this?
> > >
> > > If the kernel has always worked this way, I would say that Go is doing
> > > the wrong thing here.  If the kernel used to work properly, and then
> > > changed, then it's a regression on the kernel side.
> > >
> > > So which is it?
> >
> > I don't work on the kernel, so I can't tell you which it is.  You will
> > have to decide.
>
> As you have the userspace code, it should be easier for you to test this
> on an older kernel.  I don't have your userspace code...

Sorry, I'm not sure what you are asking.

I've attached a sample Go program.  On kernel version 2.6.32 this
program exits 0.  On kernel version 5.7.17 it prints

got "" want "./foo\x00"

and exits with status 1.

This program hardcodes the string "/proc/self/cmdline" for
convenience, but of course the same results would happen if this were
a generic copy program that somebody invoked with /proc/self/cmdline
as a command line option.

I could write the same program in C easily enough, by explicitly
calling copy_file_range.  Would it help to see a sample C program?


> > From my perspective, as a kernel user rather than a kernel developer,
> > a system call that silently fails for certain files and that provides
> > no way to determine either 1) ahead of time that the system call will
> > fail, or 2) after the call that the system call did fail, is a useless
> > system call.
>
> Great, then don't use copy_file_range() yet as it seems like it fits
> that category at the moment :)

That seems like an unfortunate result, but if that is the determining
opinion then I guess that is what we will have to do in the Go
standard library.

Ian

[-- Attachment #2: foo7.go --]
[-- Type: text/x-go, Size: 972 bytes --]

package main

import (
	"bytes"
	"fmt"
	"io"
	"io/ioutil"
	"os"
)

func main() {
	tmpfile, err := ioutil.TempFile("", "copy_file_range")
	if err != nil {
		fmt.Fprint(os.Stderr, err)
		os.Exit(1)
	}
	status := copy(tmpfile)
	os.Remove(tmpfile.Name())
	os.Exit(status)
}

func copy(tmpfile *os.File) int {
	cmdline, err := os.Open("/proc/self/cmdline")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		return 1
	}
	defer cmdline.Close()
	if _, err := io.Copy(tmpfile, cmdline); err != nil {
		fmt.Fprintf(os.Stderr, "copy failed: %v\n", err)
		return 1
	}
	if err := tmpfile.Close(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		return 1
	}
	old, err := ioutil.ReadFile("/proc/self/cmdline")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		return 1
	}
	new, err := ioutil.ReadFile(tmpfile.Name())
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		return 1
	}
	if !bytes.Equal(old, new) {
		fmt.Fprintf(os.Stderr, "got %q want %q\n", new, old)
		return 1
	}
	return 0
}

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Dave Chinner]

On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > files in the first place?  They can not seek (well most can not), so
> > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > problem that userspace should not do.
> > 
> > This may have been covered elsewhere, but it's not that people are
> > saying "let's use copy_file_range on files in /proc."  It's that the
> > Go language standard library provides an interface to operating system
> > files.  When Go code uses the standard library function io.Copy to
> > copy the contents of one open file to another open file, then on Linux
> > kernels 5.3 and greater the Go standard library will use the
> > copy_file_range system call.  That seems to be exactly what
> > copy_file_range is intended for.  Unfortunately it appears that when
> > people writing Go code open a file in /proc and use io.Copy the
> > contents to another open file, copy_file_range does nothing and
> > reports success.  There isn't anything on the copy_file_range man page
> > explaining this limitation, and there isn't any documented way to know
> > that the Go standard library should not use copy_file_range on certain
> > files.
> 
> But, is this a bug in the kernel in that the syscall being made is not
> working properly, or a bug in that Go decided to do this for all types
> of files not knowing that some types of files can not handle this?
> 
> If the kernel has always worked this way, I would say that Go is doing
> the wrong thing here.  If the kernel used to work properly, and then
> changed, then it's a regression on the kernel side.
> 
> So which is it?

Both Al Viro and myself have said "copy file range is not a generic
method for copying data between two file descriptors". It is a
targetted solution for *regular files only* on filesystems that store
persistent data and can accelerate the data copy in some way (e.g.
clone, server side offload, hardware offlead, etc). It is not
intended as a copy mechanism for copying data from one random file
descriptor to another.

The use of it as a general file copy mechanism in the Go system
library is incorrect and wrong. It is a userspace bug.  Userspace
has done the wrong thing, userspace needs to be fixed.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Ian Lance Taylor]

On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner <david@fromorbit.com> wrote:
>
> On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > files in the first place?  They can not seek (well most can not), so
> > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > problem that userspace should not do.
> > >
> > > This may have been covered elsewhere, but it's not that people are
> > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > Go language standard library provides an interface to operating system
> > > files.  When Go code uses the standard library function io.Copy to
> > > copy the contents of one open file to another open file, then on Linux
> > > kernels 5.3 and greater the Go standard library will use the
> > > copy_file_range system call.  That seems to be exactly what
> > > copy_file_range is intended for.  Unfortunately it appears that when
> > > people writing Go code open a file in /proc and use io.Copy the
> > > contents to another open file, copy_file_range does nothing and
> > > reports success.  There isn't anything on the copy_file_range man page
> > > explaining this limitation, and there isn't any documented way to know
> > > that the Go standard library should not use copy_file_range on certain
> > > files.
> >
> > But, is this a bug in the kernel in that the syscall being made is not
> > working properly, or a bug in that Go decided to do this for all types
> > of files not knowing that some types of files can not handle this?
> >
> > If the kernel has always worked this way, I would say that Go is doing
> > the wrong thing here.  If the kernel used to work properly, and then
> > changed, then it's a regression on the kernel side.
> >
> > So which is it?
>
> Both Al Viro and myself have said "copy file range is not a generic
> method for copying data between two file descriptors". It is a
> targetted solution for *regular files only* on filesystems that store
> persistent data and can accelerate the data copy in some way (e.g.
> clone, server side offload, hardware offlead, etc). It is not
> intended as a copy mechanism for copying data from one random file
> descriptor to another.
>
> The use of it as a general file copy mechanism in the Go system
> library is incorrect and wrong. It is a userspace bug.  Userspace
> has done the wrong thing, userspace needs to be fixed.

OK, we'll take it out.

I'll just make one last plea that I think that copy_file_range could
be much more useful if there were some way that a program could know
whether it would work or not.  It's pretty unfortunate that we can't
use it in the Go standard library, or, indeed, in any general purpose
code, in any language, that is intended to support arbitrary file
names.  To be pedantically clear, I'm not saying that copy_file_range
should work on all file systems.  I'm only saying that on file systems
for which it doesn't work it should fail rather than silently
returning success without doing anything.

Ian

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Dave Chinner]

On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> > > Filesystems such as procfs and sysfs generate their content at
> > > runtime. This implies the file sizes do not usually match the
> > > amount of data that can be read from the file, and that seeking
> > > may not work as intended.
> > >
> > > This will be useful to disallow copy_file_range with input files
> > > from such filesystems.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > > ---
> > > I first thought of adding a new field to struct file_operations,
> > > but that doesn't quite scale as every single file creation
> > > operation would need to be modified.
> >
> > Even so, you missed a load of filesystems in the kernel with this patch
> > series, what makes the ones you did mark here different from the
> > "internal" filesystems that you did not?
> >
> > This feels wrong, why is userspace suddenly breaking?  What changed in
> > the kernel that caused this?  Procfs has been around for a _very_ long
> > time :)
> 
> That would be because of (v5.3):
> 
> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> 
> The intention of this change (series) was to allow server side copy
> for nfs and cifs via copy_file_range().
> This is mostly work by Dave Chinner that I picked up following requests
> from the NFS folks.
> 
> But the above change also includes this generic change:
> 
> -       /* this could be relaxed once a method supports cross-fs copies */
> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> -               return -EXDEV;
> -

This isn't the problem.

The problem is that proc sets the file size to zero length, so
if you attempt to CFR from one proc file to another it will still
report "zero bytes copied" because the source file is zero length.

The other problem is that if the write fails, the generated data
from the /proc file gets thrown away - the splice code treats write
failures like a short read and hence the data sent to the failed
write is consumed and lost.

This has nothing to do with cross-fs cfr support - it's just one
mechanism that can be used to expose the problems that using CFR on
pipes that masquerade as regular files causes.

Userspace can't even tell that CFR failed incorrectly, because the
files that it returns immediate EOF on are zero length. Nor can
userspace know taht a short read tossed away data, because it might
actually be a short read rather than a write failure...

> Our option now are:
> - Restore the cross-fs restriction into generic_copy_file_range()
> - Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does

- Stop trying using cfr for things it was never intended for.

Anyone using cfr has to be prepared for it to fail and do the copy
manually themselves. If you can't tell from userspace if a file has
data in it without actually calling read(), then you can't use
copy_file_range() on it...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Dave Chinner]

On Fri, Feb 12, 2021 at 03:07:39PM -0800, Ian Lance Taylor wrote:
> On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > > files in the first place?  They can not seek (well most can not), so
> > > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > > problem that userspace should not do.
> > > >
> > > > This may have been covered elsewhere, but it's not that people are
> > > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > > Go language standard library provides an interface to operating system
> > > > files.  When Go code uses the standard library function io.Copy to
> > > > copy the contents of one open file to another open file, then on Linux
> > > > kernels 5.3 and greater the Go standard library will use the
> > > > copy_file_range system call.  That seems to be exactly what
> > > > copy_file_range is intended for.  Unfortunately it appears that when
> > > > people writing Go code open a file in /proc and use io.Copy the
> > > > contents to another open file, copy_file_range does nothing and
> > > > reports success.  There isn't anything on the copy_file_range man page
> > > > explaining this limitation, and there isn't any documented way to know
> > > > that the Go standard library should not use copy_file_range on certain
> > > > files.
> > >
> > > But, is this a bug in the kernel in that the syscall being made is not
> > > working properly, or a bug in that Go decided to do this for all types
> > > of files not knowing that some types of files can not handle this?
> > >
> > > If the kernel has always worked this way, I would say that Go is doing
> > > the wrong thing here.  If the kernel used to work properly, and then
> > > changed, then it's a regression on the kernel side.
> > >
> > > So which is it?
> >
> > Both Al Viro and myself have said "copy file range is not a generic
> > method for copying data between two file descriptors". It is a
> > targetted solution for *regular files only* on filesystems that store
> > persistent data and can accelerate the data copy in some way (e.g.
> > clone, server side offload, hardware offlead, etc). It is not
> > intended as a copy mechanism for copying data from one random file
> > descriptor to another.
> >
> > The use of it as a general file copy mechanism in the Go system
> > library is incorrect and wrong. It is a userspace bug.  Userspace
> > has done the wrong thing, userspace needs to be fixed.
> 
> OK, we'll take it out.
> 
> I'll just make one last plea that I think that copy_file_range could
> be much more useful if there were some way that a program could know
> whether it would work or not.

If you can't tell from userspace that a file has data in it other
than by calling read() on it, then you can't use cfr on it.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Darrick J. Wong]

On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> On Fri, Feb 12, 2021 at 03:07:39PM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner <david@fromorbit.com> wrote:
> > >
> > > On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > > > files in the first place?  They can not seek (well most can not), so
> > > > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > > > problem that userspace should not do.
> > > > >
> > > > > This may have been covered elsewhere, but it's not that people are
> > > > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > > > Go language standard library provides an interface to operating system
> > > > > files.  When Go code uses the standard library function io.Copy to
> > > > > copy the contents of one open file to another open file, then on Linux
> > > > > kernels 5.3 and greater the Go standard library will use the
> > > > > copy_file_range system call.  That seems to be exactly what
> > > > > copy_file_range is intended for.  Unfortunately it appears that when
> > > > > people writing Go code open a file in /proc and use io.Copy the
> > > > > contents to another open file, copy_file_range does nothing and
> > > > > reports success.  There isn't anything on the copy_file_range man page
> > > > > explaining this limitation, and there isn't any documented way to know
> > > > > that the Go standard library should not use copy_file_range on certain
> > > > > files.
> > > >
> > > > But, is this a bug in the kernel in that the syscall being made is not
> > > > working properly, or a bug in that Go decided to do this for all types
> > > > of files not knowing that some types of files can not handle this?
> > > >
> > > > If the kernel has always worked this way, I would say that Go is doing
> > > > the wrong thing here.  If the kernel used to work properly, and then
> > > > changed, then it's a regression on the kernel side.
> > > >
> > > > So which is it?
> > >
> > > Both Al Viro and myself have said "copy file range is not a generic
> > > method for copying data between two file descriptors". It is a
> > > targetted solution for *regular files only* on filesystems that store
> > > persistent data and can accelerate the data copy in some way (e.g.
> > > clone, server side offload, hardware offlead, etc). It is not
> > > intended as a copy mechanism for copying data from one random file
> > > descriptor to another.
> > >
> > > The use of it as a general file copy mechanism in the Go system
> > > library is incorrect and wrong. It is a userspace bug.  Userspace
> > > has done the wrong thing, userspace needs to be fixed.
> > 
> > OK, we'll take it out.
> > 
> > I'll just make one last plea that I think that copy_file_range could
> > be much more useful if there were some way that a program could know
> > whether it would work or not.

Well... we could always implement a CFR_DRYRUN flag that would run
through all the parameter validation and return 0 just before actually
starting any real copying logic.  But that wouldn't itself solve the
problem that there are very old virtual filesystems in Linux that have
zero-length regular files that behave like a pipe.

> If you can't tell from userspace that a file has data in it other
> than by calling read() on it, then you can't use cfr on it.

I don't know how to do that, Dave. :)

Frankly I'm with the Go developers on this -- one should detect c_f_r by
calling it and if it errors out then fall back to the usual userspace
buffer copy strategy.

That still means we need to fix the kernel WRT these weird old
filesystems.  One of...

1. Get rid of the generic fallback completely, since splice only copies
64k at a time and ... yay?  I guess it at least passes generic/521 and
generic/522 these days.

2. Keep it, but change c_f_r to require that both files have a
->copy_file_range implementation.  If they're the same then we'll call
the function pointer, if not, we call the generic fallback.  This at
least gets us back to the usual behavior which is that filesystems have
to opt in to new functionality (== we assume they QA'd all the wunnerful
combinations).

3. #2, but fix the generic fallback to not suck so badly.  That sounds
like someone (else's) 2yr project. :P

--D

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

Re: [PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range

[Al Viro]

On Fri, Feb 12, 2021 at 12:43:59PM +0800, Nicolas Boichat wrote:
> We hit an issue when upgrading Go compiler from 1.13 to 1.15 [1],
> as we use Go's `io.Copy` to copy the content of
> `/sys/kernel/debug/tracing/trace` to a temporary file.
> 
> Under the hood, Go 1.15 uses `copy_file_range` syscall to
> optimize the copy operation. However, that fails to copy any
> content when the input file is from tracefs, with an apparent
> size of 0 (but there is still content when you `cat` it, of
> course).
> 
> >From discussions in [2][3], it is clear that copy_file_range
> cannot be properly implemented on filesystems where the content
> is generated at runtime: the file size is incorrect (because it
> is unknown before the content is generated), and seeking in such
> files (as required by partial writes) is unlikely to work
> correctly.
> 
> With this patch, Go's `io.Copy` gracefully falls back to a normal
> read/write file copy.
> 
> I'm not 100% sure which stable tree this should go in, I'd say
> at least >=5.3 since this is what introduced support for
> cross-filesystem copy_file_range (and where most users are
> somewhat likely to hit this issue). But let's discuss the patch
> series first.

No.  This is *NOT* an fs-wide flag.  Decision regarding the
usability of copy_file_range() is on per-file basis.

The real constraint is "can freely seek back and expect to
find consistent data".  That is what's violated for seq_file.
And frankly, I would rather add a flag and have seq_open()
(and other suckers, if any) clear it.  With check being
"has both FMODE_PREAD and this new flag".

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Dave Chinner]

On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> > On Fri, Feb 12, 2021 at 03:07:39PM -0800, Ian Lance Taylor wrote:
> > > On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner <david@fromorbit.com> wrote:
> > > >
> > > > On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > > > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > > > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > Why are people trying to use copy_file_range on simple /proc and /sys
> > > > > > > files in the first place?  They can not seek (well most can not), so
> > > > > > > that feels like a "oh look, a new syscall, let's use it everywhere!"
> > > > > > > problem that userspace should not do.
> > > > > >
> > > > > > This may have been covered elsewhere, but it's not that people are
> > > > > > saying "let's use copy_file_range on files in /proc."  It's that the
> > > > > > Go language standard library provides an interface to operating system
> > > > > > files.  When Go code uses the standard library function io.Copy to
> > > > > > copy the contents of one open file to another open file, then on Linux
> > > > > > kernels 5.3 and greater the Go standard library will use the
> > > > > > copy_file_range system call.  That seems to be exactly what
> > > > > > copy_file_range is intended for.  Unfortunately it appears that when
> > > > > > people writing Go code open a file in /proc and use io.Copy the
> > > > > > contents to another open file, copy_file_range does nothing and
> > > > > > reports success.  There isn't anything on the copy_file_range man page
> > > > > > explaining this limitation, and there isn't any documented way to know
> > > > > > that the Go standard library should not use copy_file_range on certain
> > > > > > files.
> > > > >
> > > > > But, is this a bug in the kernel in that the syscall being made is not
> > > > > working properly, or a bug in that Go decided to do this for all types
> > > > > of files not knowing that some types of files can not handle this?
> > > > >
> > > > > If the kernel has always worked this way, I would say that Go is doing
> > > > > the wrong thing here.  If the kernel used to work properly, and then
> > > > > changed, then it's a regression on the kernel side.
> > > > >
> > > > > So which is it?
> > > >
> > > > Both Al Viro and myself have said "copy file range is not a generic
> > > > method for copying data between two file descriptors". It is a
> > > > targetted solution for *regular files only* on filesystems that store
> > > > persistent data and can accelerate the data copy in some way (e.g.
> > > > clone, server side offload, hardware offlead, etc). It is not
> > > > intended as a copy mechanism for copying data from one random file
> > > > descriptor to another.
> > > >
> > > > The use of it as a general file copy mechanism in the Go system
> > > > library is incorrect and wrong. It is a userspace bug.  Userspace
> > > > has done the wrong thing, userspace needs to be fixed.
> > > 
> > > OK, we'll take it out.
> > > 
> > > I'll just make one last plea that I think that copy_file_range could
> > > be much more useful if there were some way that a program could know
> > > whether it would work or not.
> 
> Well... we could always implement a CFR_DRYRUN flag that would run
> through all the parameter validation and return 0 just before actually
> starting any real copying logic.  But that wouldn't itself solve the
> problem that there are very old virtual filesystems in Linux that have
> zero-length regular files that behave like a pipe.
> 
> > If you can't tell from userspace that a file has data in it other
> > than by calling read() on it, then you can't use cfr on it.
> 
> I don't know how to do that, Dave. :)

If stat returns a non-zero size, then userspace knows it has at
least that much data in it, whether it be zeros or previously
written data. cfr will copy that data. The special zero length
regular pipe files fail this simple "how much data is there to copy
in this file" check...

> Frankly I'm with the Go developers on this -- one should detect c_f_r by
> calling it and if it errors out then fall back to the usual userspace
> buffer copy strategy.
> 
> That still means we need to fix the kernel WRT these weird old
> filesystems.  One of...

And that is the whole problem here, not that cfr is failing. cfr is
behaving correctly and consistently as the filesystem is telling the
kernel there is no data in the file (i.e. size = 0).

> 1. Get rid of the generic fallback completely, since splice only copies
> 64k at a time and ... yay?  I guess it at least passes generic/521 and
> generic/522 these days.

I've had a few people ask me for cfr to not fall back to a manual
copy because they only want it to do something if it can accelerate
the copy to be faster than userspace can copy the data itself. If
the filesystem can't optimise the copy in some way, they want to
know so they can do something else of their own chosing.

Hence this seems like the sane option to take here...

> 2. Keep it, but change c_f_r to require that both files have a
> ->copy_file_range implementation.  If they're the same then we'll call
> the function pointer, if not, we call the generic fallback.  This at
> least gets us back to the usual behavior which is that filesystems have
> to opt in to new functionality (== we assume they QA'd all the wunnerful
> combinations).

That doesn't address the "write failure turns into short read"
problem with the splice path...

> 3. #2, but fix the generic fallback to not suck so badly.  That sounds
> like someone (else's) 2yr project. :P

Not mine, either.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Ian Lance Taylor]

On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner <david@fromorbit.com> wrote:
>
> On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> >
> > > If you can't tell from userspace that a file has data in it other
> > > than by calling read() on it, then you can't use cfr on it.
> >
> > I don't know how to do that, Dave. :)
>
> If stat returns a non-zero size, then userspace knows it has at
> least that much data in it, whether it be zeros or previously
> written data. cfr will copy that data. The special zero length
> regular pipe files fail this simple "how much data is there to copy
> in this file" check...

This suggests that if the Go standard library sees that
copy_file_range reads zero bytes, we should assume that it failed, and
should use the fallback path as though copy_file_range returned
EOPNOTSUPP or EINVAL.  This will cause an extra system call for an
empty file, but as long as copy_file_range does not return an error
for cases that it does not support we are going to need an extra
system call anyhow.

Does that seem like a possible mitigation?  That is, are there cases
where copy_file_range will fail to do a correct copy, and will return
success, and will not return zero?

Ian

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Nicolas Boichat]

On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor <iant@golang.org> wrote:
>
> On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> > >
> > > > If you can't tell from userspace that a file has data in it other
> > > > than by calling read() on it, then you can't use cfr on it.
> > >
> > > I don't know how to do that, Dave. :)
> >
> > If stat returns a non-zero size, then userspace knows it has at
> > least that much data in it, whether it be zeros or previously
> > written data. cfr will copy that data. The special zero length
> > regular pipe files fail this simple "how much data is there to copy
> > in this file" check...
>
> This suggests that if the Go standard library sees that
> copy_file_range reads zero bytes, we should assume that it failed, and
> should use the fallback path as though copy_file_range returned
> EOPNOTSUPP or EINVAL.  This will cause an extra system call for an
> empty file, but as long as copy_file_range does not return an error
> for cases that it does not support we are going to need an extra
> system call anyhow.
>
> Does that seem like a possible mitigation?  That is, are there cases
> where copy_file_range will fail to do a correct copy, and will return
> success, and will not return zero?

I'm a bit worried about the sysfs files that report a 4096 bytes file
size, for 2 reasons:
 - I'm not sure if the content _can_ actually be longer (I couldn't
find a counterexample)
 - If you're unlucky enough to have a partial write in the output
filesystem, you'll get a non-zero return value and probably corrupted
content.

>
> Ian

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Amir Goldstein]

On Mon, Feb 15, 2021 at 3:27 AM Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor <iant@golang.org> wrote:
> >
> > On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner <david@fromorbit.com> wrote:
> > >
> > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> > > >
> > > > > If you can't tell from userspace that a file has data in it other
> > > > > than by calling read() on it, then you can't use cfr on it.
> > > >
> > > > I don't know how to do that, Dave. :)
> > >
> > > If stat returns a non-zero size, then userspace knows it has at
> > > least that much data in it, whether it be zeros or previously
> > > written data. cfr will copy that data. The special zero length
> > > regular pipe files fail this simple "how much data is there to copy
> > > in this file" check...
> >
> > This suggests that if the Go standard library sees that
> > copy_file_range reads zero bytes, we should assume that it failed, and
> > should use the fallback path as though copy_file_range returned
> > EOPNOTSUPP or EINVAL.  This will cause an extra system call for an
> > empty file, but as long as copy_file_range does not return an error
> > for cases that it does not support we are going to need an extra
> > system call anyhow.
> >
> > Does that seem like a possible mitigation?  That is, are there cases
> > where copy_file_range will fail to do a correct copy, and will return
> > success, and will not return zero?
>
> I'm a bit worried about the sysfs files that report a 4096 bytes file
> size, for 2 reasons:
>  - I'm not sure if the content _can_ actually be longer (I couldn't
> find a counterexample)
>  - If you're unlucky enough to have a partial write in the output
> filesystem, you'll get a non-zero return value and probably corrupted
> content.
>

First of all, I am in favor of fixing the regression in the kernel caused
by the change of behavior in v5.3.

Having said that, I don't think it is a good idea to use ANY tool to copy
a zero size pseudo file.
rsync doesn't copy any data either if you try to use it to copy tracing into
a temp file.
I think it is perfectly sane for any tool to check file size before trying
to read/copy.

w.r.t. short write/short read, did you consider using the off_in/off_out
arguments? I *think* current kernel CFR should be safe to use as long
as the tool:
1. Checks file size before copy
2. Does not try to copy a range beyond EOF
3. Pass off_in/off_out args and verify that off_in/off_out advances
    as expected

Thanks,
Amir.

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Amir Goldstein]

On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Fri, Feb 12, 2021 at 12:05:14PM +0000, Luis Henriques wrote:
> >> Greg KH <gregkh@linuxfoundation.org> writes:
> >>
> >> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> >> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >> >> >
> >> >> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> >> >> > > Filesystems such as procfs and sysfs generate their content at
> >> >> > > runtime. This implies the file sizes do not usually match the
> >> >> > > amount of data that can be read from the file, and that seeking
> >> >> > > may not work as intended.
> >> >> > >
> >> >> > > This will be useful to disallow copy_file_range with input files
> >> >> > > from such filesystems.
> >> >> > >
> >> >> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> >> >> > > ---
> >> >> > > I first thought of adding a new field to struct file_operations,
> >> >> > > but that doesn't quite scale as every single file creation
> >> >> > > operation would need to be modified.
> >> >> >
> >> >> > Even so, you missed a load of filesystems in the kernel with this patch
> >> >> > series, what makes the ones you did mark here different from the
> >> >> > "internal" filesystems that you did not?
> >> >> >
> >> >> > This feels wrong, why is userspace suddenly breaking?  What changed in
> >> >> > the kernel that caused this?  Procfs has been around for a _very_ long
> >> >> > time :)
> >> >>
> >> >> That would be because of (v5.3):
> >> >>
> >> >> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> >> >>
> >> >> The intention of this change (series) was to allow server side copy
> >> >> for nfs and cifs via copy_file_range().
> >> >> This is mostly work by Dave Chinner that I picked up following requests
> >> >> from the NFS folks.
> >> >>
> >> >> But the above change also includes this generic change:
> >> >>
> >> >> -       /* this could be relaxed once a method supports cross-fs copies */
> >> >> -       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >> >> -               return -EXDEV;
> >> >> -
> >> >>
> >> >> The change of behavior was documented in the commit message.
> >> >> It was also documented in:
> >> >>
> >> >> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
> >> >>
> >> >> I think our rationale for the generic change was:
> >> >> "Why not? What could go wrong? (TM)"
> >> >> I am not sure if any workload really gained something from this
> >> >> kernel cross-fs CFR.
> >> >
> >> > Why not put that check back?
> >> >
> >> >> In retrospect, I think it would have been safer to allow cross-fs CFR
> >> >> only to the filesystems that implement ->{copy,remap}_file_range()...
> >> >
> >> > Why not make this change?  That seems easier and should fix this for
> >> > everyone, right?
> >> >
> >> >> Our option now are:
> >> >> - Restore the cross-fs restriction into generic_copy_file_range()
> >> >
> >> > Yes.
> >> >
> >>
> >> Restoring this restriction will actually change the current cephfs CFR
> >> behaviour.  Since that commit we have allowed doing remote copies between
> >> different filesystems within the same ceph cluster.  See commit
> >> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
> >> the same cluster").
> >>
> >> Although I'm not aware of any current users for this scenario, the
> >> performance impact can actually be huge as it's the difference between
> >> asking the OSDs for copying a file and doing a full read+write on the
> >> client side.
> >
> > Regression in performance is ok if it fixes a regression for things that
> > used to work just fine in the past :)
> >
> > First rule, make it work.
>
> Sure, I just wanted to point out that *maybe* there are other options than
> simply reverting that commit :-)
>
> Something like the patch below (completely untested!) should revert to the
> old behaviour in filesystems that don't implement the CFR syscall.
>
> Cheers,
> --
> Luis
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..bf5dccc43cc9 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>                                                        file_out, pos_out,
>                                                        len, flags);
>
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);
> +       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +               return -EXDEV;
> +       else
> +               generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> +                                       flags);
>  }
>

Which kernel is this patch based on?

At this point, I am with Dave and Darrick on not falling back to
generic_copy_file_range() at all.

We do not have proof of any workload that benefits from it and the
above patch does not protect from a wierd use case of trying to copy a file
from sysfs to sysfs.

I am indecisive about what should be done with generic_copy_file_range()
called as fallback from within filesystems.

I think the wise choice is to not do the fallback in any case, but this is up
to the specific filesystem maintainers to decide.

Thanks,
Amir.

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Greg KH]

On Mon, Feb 15, 2021 at 09:25:36AM +0800, Nicolas Boichat wrote:
> On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor <iant@golang.org> wrote:
> >
> > On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner <david@fromorbit.com> wrote:
> > >
> > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> > > >
> > > > > If you can't tell from userspace that a file has data in it other
> > > > > than by calling read() on it, then you can't use cfr on it.
> > > >
> > > > I don't know how to do that, Dave. :)
> > >
> > > If stat returns a non-zero size, then userspace knows it has at
> > > least that much data in it, whether it be zeros or previously
> > > written data. cfr will copy that data. The special zero length
> > > regular pipe files fail this simple "how much data is there to copy
> > > in this file" check...
> >
> > This suggests that if the Go standard library sees that
> > copy_file_range reads zero bytes, we should assume that it failed, and
> > should use the fallback path as though copy_file_range returned
> > EOPNOTSUPP or EINVAL.  This will cause an extra system call for an
> > empty file, but as long as copy_file_range does not return an error
> > for cases that it does not support we are going to need an extra
> > system call anyhow.
> >
> > Does that seem like a possible mitigation?  That is, are there cases
> > where copy_file_range will fail to do a correct copy, and will return
> > success, and will not return zero?
> 
> I'm a bit worried about the sysfs files that report a 4096 bytes file
> size, for 2 reasons:
>  - I'm not sure if the content _can_ actually be longer (I couldn't
> find a counterexample)

There are quite a few, look for binary sysfs files that are pipes from
hardware/firmware resources to userspace.  /sys/firmware/efi/efivars/
has a number of them if you want to play around with it.

thanks,

greg k-h

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
...
>> Sure, I just wanted to point out that *maybe* there are other options than
>> simply reverting that commit :-)
>>
>> Something like the patch below (completely untested!) should revert to the
>> old behaviour in filesystems that don't implement the CFR syscall.
>>
>> Cheers,
>> --
>> Luis
>>
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..bf5dccc43cc9 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>>                                                        file_out, pos_out,
>>                                                        len, flags);
>>
>> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> -                                      flags);
>> +       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> +               return -EXDEV;
>> +       else
>> +               generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> +                                       flags);
>>  }
>>
>
> Which kernel is this patch based on?

It was v5.11-rc7.

> At this point, I am with Dave and Darrick on not falling back to
> generic_copy_file_range() at all.
>
> We do not have proof of any workload that benefits from it and the
> above patch does not protect from a wierd use case of trying to copy a file
> from sysfs to sysfs.
>

Ok, cool.  I can post a new patch doing just that.  I guess that function
do_copy_file_range() can be dropped in that case.

> I am indecisive about what should be done with generic_copy_file_range()
> called as fallback from within filesystems.
>
> I think the wise choice is to not do the fallback in any case, but this is up
> to the specific filesystem maintainers to decide.

I see what you mean.  You're suggesting to have userspace handle all the
-EOPNOTSUPP and -EXDEV errors.  Would you rather have a patch that also
removes all the calls to generic_copy_file_range() function?  And that
function can also be deleted too, of course.

Cheers,
-- 
Luis

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Luis Henriques <lhenriques@suse.de> writes:

> Amir Goldstein <amir73il@gmail.com> writes:
>
>> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
> ...
>>> Sure, I just wanted to point out that *maybe* there are other options than
>>> simply reverting that commit :-)
>>>
>>> Something like the patch below (completely untested!) should revert to the
>>> old behaviour in filesystems that don't implement the CFR syscall.
>>>
>>> Cheers,
>>> --
>>> Luis
>>>
>>> diff --git a/fs/read_write.c b/fs/read_write.c
>>> index 75f764b43418..bf5dccc43cc9 100644
>>> --- a/fs/read_write.c
>>> +++ b/fs/read_write.c
>>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>>>                                                        file_out, pos_out,
>>>                                                        len, flags);
>>>
>>> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>>> -                                      flags);
>>> +       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>>> +               return -EXDEV;
>>> +       else
>>> +               generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>>> +                                       flags);
>>>  }
>>>
>>
>> Which kernel is this patch based on?
>
> It was v5.11-rc7.
>
>> At this point, I am with Dave and Darrick on not falling back to
>> generic_copy_file_range() at all.
>>
>> We do not have proof of any workload that benefits from it and the
>> above patch does not protect from a wierd use case of trying to copy a file
>> from sysfs to sysfs.
>>
>
> Ok, cool.  I can post a new patch doing just that.  I guess that function
> do_copy_file_range() can be dropped in that case.
>
>> I am indecisive about what should be done with generic_copy_file_range()
>> called as fallback from within filesystems.
>>
>> I think the wise choice is to not do the fallback in any case, but this is up
>> to the specific filesystem maintainers to decide.
>
> I see what you mean.  You're suggesting to have userspace handle all the
> -EOPNOTSUPP and -EXDEV errors.  Would you rather have a patch that also
> removes all the calls to generic_copy_file_range() function?  And that
> function can also be deleted too, of course.

Here's a first stab at this patch.  Hopefully I didn't forgot anything
here.  Let me know if you prefer the more conservative approach, i.e. not
touching any of the filesystems and let them use generic_copy_file_range.

Once everyone agrees on the final solution, I can follow-up with the
manpages update.

Cheers,
-- 
Luis

From e1b37e80b12601d56f792bd19377d3e5208188ef Mon Sep 17 00:00:00 2001
From: Luis Henriques <lhenriques@suse.de>
Date: Fri, 12 Feb 2021 18:03:23 +0000
Subject: [PATCH] vfs: prevent copy_file_range to copy across devices

Nicolas Boichat reported an issue when trying to use the copy_file_range
syscall on a tracefs file.  It failed silently because the file content is
generated on-the-fly (reporting a size of zero) and copy_file_range needs
to know in advance how much data is present.

This commit effectively reverts 5dae222a5ff0 ("vfs: allow copy_file_range to
copy across devices").  Now the copy is done only if the filesystems for source
and destination files are the same and they implement this syscall.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Cc: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
 fs/ceph/file.c     | 21 +++------------
 fs/cifs/cifsfs.c   |  3 ---
 fs/fuse/file.c     | 21 +++------------
 fs/nfs/nfs4file.c  | 20 +++-----------
 fs/read_write.c    | 65 ++++++++--------------------------------------
 include/linux/fs.h |  3 ---
 6 files changed, 20 insertions(+), 113 deletions(-)

diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 209535d5b8d3..639bd7bfaea9 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -2261,9 +2261,9 @@ static ssize_t ceph_do_objects_copy(struct ceph_inode_info *src_ci, u64 *src_off
 	return bytes;
 }
 
-static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
-				      struct file *dst_file, loff_t dst_off,
-				      size_t len, unsigned int flags)
+static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
+				    struct file *dst_file, loff_t dst_off,
+				    size_t len, unsigned int flags)
 {
 	struct inode *src_inode = file_inode(src_file);
 	struct inode *dst_inode = file_inode(dst_file);
@@ -2456,21 +2456,6 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
 	return ret;
 }
 
-static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
-				    struct file *dst_file, loff_t dst_off,
-				    size_t len, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
-				     len, flags);
-
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(src_file, src_off, dst_file,
-					      dst_off, len, flags);
-	return ret;
-}
-
 const struct file_operations ceph_file_fops = {
 	.open = ceph_open,
 	.release = ceph_release,
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index e46da536ed33..8b869cc67443 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -1229,9 +1229,6 @@ static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off,
 					len, flags);
 	free_xid(xid);
 
-	if (rc == -EOPNOTSUPP || rc == -EXDEV)
-		rc = generic_copy_file_range(src_file, off, dst_file,
-					     destoff, len, flags);
 	return rc;
 }
 
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 8cccecb55fb8..0dd703278e49 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -3330,9 +3330,9 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
 	return err;
 }
 
-static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
-				      struct file *file_out, loff_t pos_out,
-				      size_t len, unsigned int flags)
+static ssize_t fuse_copy_file_range(struct file *file_in, loff_t pos_in,
+				    struct file *file_out, loff_t pos_out,
+				    size_t len, unsigned int flags)
 {
 	struct fuse_file *ff_in = file_in->private_data;
 	struct fuse_file *ff_out = file_out->private_data;
@@ -3439,21 +3439,6 @@ static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
 	return err;
 }
 
-static ssize_t fuse_copy_file_range(struct file *src_file, loff_t src_off,
-				    struct file *dst_file, loff_t dst_off,
-				    size_t len, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __fuse_copy_file_range(src_file, src_off, dst_file, dst_off,
-				     len, flags);
-
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(src_file, src_off, dst_file,
-					      dst_off, len, flags);
-	return ret;
-}
-
 static const struct file_operations fuse_file_operations = {
 	.llseek		= fuse_file_llseek,
 	.read_iter	= fuse_file_read_iter,
diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index 57b3821d975a..60998209e310 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -133,9 +133,9 @@ nfs4_file_flush(struct file *file, fl_owner_t id)
 }
 
 #ifdef CONFIG_NFS_V4_2
-static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
-				      struct file *file_out, loff_t pos_out,
-				      size_t count, unsigned int flags)
+static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
+				    struct file *file_out, loff_t pos_out,
+				    size_t count, unsigned int flags)
 {
 	struct nfs42_copy_notify_res *cn_resp = NULL;
 	struct nl4_server *nss = NULL;
@@ -189,20 +189,6 @@ static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
 	return ret;
 }
 
-static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
-				    struct file *file_out, loff_t pos_out,
-				    size_t count, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __nfs4_copy_file_range(file_in, pos_in, file_out, pos_out, count,
-				     flags);
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(file_in, pos_in, file_out,
-					      pos_out, count, flags);
-	return ret;
-}
-
 static loff_t nfs4_file_llseek(struct file *filep, loff_t offset, int whence)
 {
 	loff_t ret;
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..87bf9efd7f71 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1358,58 +1358,6 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
 }
 #endif
 
-/**
- * generic_copy_file_range - copy data between two files
- * @file_in:	file structure to read from
- * @pos_in:	file offset to read from
- * @file_out:	file structure to write data to
- * @pos_out:	file offset to write data to
- * @len:	amount of data to copy
- * @flags:	copy flags
- *
- * This is a generic filesystem helper to copy data from one file to another.
- * It has no constraints on the source or destination file owners - the files
- * can belong to different superblocks and different filesystem types. Short
- * copies are allowed.
- *
- * This should be called from the @file_out filesystem, as per the
- * ->copy_file_range() method.
- *
- * Returns the number of bytes copied or a negative error indicating the
- * failure.
- */
-
-ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
-				struct file *file_out, loff_t pos_out,
-				size_t len, unsigned int flags)
-{
-	return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
-				len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
-}
-EXPORT_SYMBOL(generic_copy_file_range);
-
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1474,6 +1422,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 {
 	ssize_t ret;
 
+	/*
+	 * Allow the copy only if the filesystems for file_in and file_out are
+	 * the same, and copy_file_range is implemented.
+	 */
+	if (!file_out->f_op->copy_file_range ||
+	    (file_out->f_op->copy_file_range != file_in->f_op->copy_file_range))
+		return -EXDEV;
+
 	if (flags != 0)
 		return -EINVAL;
 
@@ -1513,8 +1469,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 		}
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
+	ret = file_out->f_op->copy_file_range(file_in, pos_in,
+					      file_out, pos_out,
+					      len, flags);
 	WARN_ON_ONCE(ret == -EOPNOTSUPP);
 done:
 	if (ret > 0) {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index fd47deea7c17..3aaf627be409 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1910,9 +1910,6 @@ extern ssize_t vfs_read(struct file *, char __user *, size_t, loff_t *);
 extern ssize_t vfs_write(struct file *, const char __user *, size_t, loff_t *);
 extern ssize_t vfs_copy_file_range(struct file *, loff_t , struct file *,
 				   loff_t, size_t, unsigned int);
-extern ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
-				       struct file *file_out, loff_t pos_out,
-				       size_t len, unsigned int flags);
 extern int generic_remap_file_range_prep(struct file *file_in, loff_t pos_in,
 					 struct file *file_out, loff_t pos_out,
 					 loff_t *count,

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Amir Goldstein]

On Mon, Feb 15, 2021 at 2:21 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Luis Henriques <lhenriques@suse.de> writes:
>
> > Amir Goldstein <amir73il@gmail.com> writes:
> >
> >> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
> > ...
> >>> Sure, I just wanted to point out that *maybe* there are other options than
> >>> simply reverting that commit :-)
> >>>
> >>> Something like the patch below (completely untested!) should revert to the
> >>> old behaviour in filesystems that don't implement the CFR syscall.
> >>>
> >>> Cheers,
> >>> --
> >>> Luis
> >>>
> >>> diff --git a/fs/read_write.c b/fs/read_write.c
> >>> index 75f764b43418..bf5dccc43cc9 100644
> >>> --- a/fs/read_write.c
> >>> +++ b/fs/read_write.c
> >>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> >>>                                                        file_out, pos_out,
> >>>                                                        len, flags);
> >>>
> >>> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> >>> -                                      flags);
> >>> +       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >>> +               return -EXDEV;
> >>> +       else
> >>> +               generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> >>> +                                       flags);
> >>>  }
> >>>
> >>
> >> Which kernel is this patch based on?
> >
> > It was v5.11-rc7.
> >
> >> At this point, I am with Dave and Darrick on not falling back to
> >> generic_copy_file_range() at all.
> >>
> >> We do not have proof of any workload that benefits from it and the
> >> above patch does not protect from a wierd use case of trying to copy a file
> >> from sysfs to sysfs.
> >>
> >
> > Ok, cool.  I can post a new patch doing just that.  I guess that function
> > do_copy_file_range() can be dropped in that case.
> >
> >> I am indecisive about what should be done with generic_copy_file_range()
> >> called as fallback from within filesystems.
> >>
> >> I think the wise choice is to not do the fallback in any case, but this is up
> >> to the specific filesystem maintainers to decide.
> >
> > I see what you mean.  You're suggesting to have userspace handle all the
> > -EOPNOTSUPP and -EXDEV errors.  Would you rather have a patch that also
> > removes all the calls to generic_copy_file_range() function?  And that
> > function can also be deleted too, of course.
>
> Here's a first stab at this patch.  Hopefully I didn't forgot anything
> here.  Let me know if you prefer the more conservative approach, i.e. not
> touching any of the filesystems and let them use generic_copy_file_range.
>

I'm fine with this one (modulu my comment below).
CC'ing fuse/cifs/nfs maintainers.
Though I don't think the FS maintainers should mind removing the fallback.
It was added by "us" (64bf5ff58dff "vfs: no fallback for ->copy_file_range()")

> Once everyone agrees on the final solution, I can follow-up with the
> manpages update.
>
> Cheers,
> --
> Luis
>
> From e1b37e80b12601d56f792bd19377d3e5208188ef Mon Sep 17 00:00:00 2001
> From: Luis Henriques <lhenriques@suse.de>
> Date: Fri, 12 Feb 2021 18:03:23 +0000
> Subject: [PATCH] vfs: prevent copy_file_range to copy across devices
>
> Nicolas Boichat reported an issue when trying to use the copy_file_range
> syscall on a tracefs file.  It failed silently because the file content is
> generated on-the-fly (reporting a size of zero) and copy_file_range needs
> to know in advance how much data is present.
>
> This commit effectively reverts 5dae222a5ff0 ("vfs: allow copy_file_range to
> copy across devices").  Now the copy is done only if the filesystems for source
> and destination files are the same and they implement this syscall.

This paragraph is not true and confusing.
This is not a revert and it does not revert the important part of cross-fs copy
for which the original commit was for.
Either rephrase this paragraph or remove it.

>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")

Please add a Link: to this discussion in lore.

> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
>  fs/ceph/file.c     | 21 +++------------
>  fs/cifs/cifsfs.c   |  3 ---
>  fs/fuse/file.c     | 21 +++------------
>  fs/nfs/nfs4file.c  | 20 +++-----------
>  fs/read_write.c    | 65 ++++++++--------------------------------------
>  include/linux/fs.h |  3 ---
>  6 files changed, 20 insertions(+), 113 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 209535d5b8d3..639bd7bfaea9 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -2261,9 +2261,9 @@ static ssize_t ceph_do_objects_copy(struct ceph_inode_info *src_ci, u64 *src_off
>         return bytes;
>  }
>
> -static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
> -                                     struct file *dst_file, loff_t dst_off,
> -                                     size_t len, unsigned int flags)
> +static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
> +                                   struct file *dst_file, loff_t dst_off,
> +                                   size_t len, unsigned int flags)
>  {
>         struct inode *src_inode = file_inode(src_file);
>         struct inode *dst_inode = file_inode(dst_file);
> @@ -2456,21 +2456,6 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
>         return ret;
>  }
>
> -static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
> -                                   struct file *dst_file, loff_t dst_off,
> -                                   size_t len, unsigned int flags)
> -{
> -       ssize_t ret;
> -
> -       ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
> -                                    len, flags);
> -
> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> -               ret = generic_copy_file_range(src_file, src_off, dst_file,
> -                                             dst_off, len, flags);
> -       return ret;
> -}
> -
>  const struct file_operations ceph_file_fops = {
>         .open = ceph_open,
>         .release = ceph_release,
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index e46da536ed33..8b869cc67443 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -1229,9 +1229,6 @@ static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off,
>                                         len, flags);
>         free_xid(xid);
>
> -       if (rc == -EOPNOTSUPP || rc == -EXDEV)
> -               rc = generic_copy_file_range(src_file, off, dst_file,
> -                                            destoff, len, flags);
>         return rc;
>  }
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 8cccecb55fb8..0dd703278e49 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -3330,9 +3330,9 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
>         return err;
>  }
>
> -static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                     struct file *file_out, loff_t pos_out,
> -                                     size_t len, unsigned int flags)
> +static ssize_t fuse_copy_file_range(struct file *file_in, loff_t pos_in,
> +                                   struct file *file_out, loff_t pos_out,
> +                                   size_t len, unsigned int flags)
>  {
>         struct fuse_file *ff_in = file_in->private_data;
>         struct fuse_file *ff_out = file_out->private_data;
> @@ -3439,21 +3439,6 @@ static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>         return err;
>  }
>
> -static ssize_t fuse_copy_file_range(struct file *src_file, loff_t src_off,
> -                                   struct file *dst_file, loff_t dst_off,
> -                                   size_t len, unsigned int flags)
> -{
> -       ssize_t ret;
> -
> -       ret = __fuse_copy_file_range(src_file, src_off, dst_file, dst_off,
> -                                    len, flags);
> -
> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> -               ret = generic_copy_file_range(src_file, src_off, dst_file,
> -                                             dst_off, len, flags);
> -       return ret;
> -}
> -
>  static const struct file_operations fuse_file_operations = {
>         .llseek         = fuse_file_llseek,
>         .read_iter      = fuse_file_read_iter,
> diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
> index 57b3821d975a..60998209e310 100644
> --- a/fs/nfs/nfs4file.c
> +++ b/fs/nfs/nfs4file.c
> @@ -133,9 +133,9 @@ nfs4_file_flush(struct file *file, fl_owner_t id)
>  }
>
>  #ifdef CONFIG_NFS_V4_2
> -static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                     struct file *file_out, loff_t pos_out,
> -                                     size_t count, unsigned int flags)
> +static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
> +                                   struct file *file_out, loff_t pos_out,
> +                                   size_t count, unsigned int flags)
>  {
>         struct nfs42_copy_notify_res *cn_resp = NULL;
>         struct nl4_server *nss = NULL;
> @@ -189,20 +189,6 @@ static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>         return ret;
>  }
>
> -static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                   struct file *file_out, loff_t pos_out,
> -                                   size_t count, unsigned int flags)
> -{
> -       ssize_t ret;
> -
> -       ret = __nfs4_copy_file_range(file_in, pos_in, file_out, pos_out, count,
> -                                    flags);
> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> -               ret = generic_copy_file_range(file_in, pos_in, file_out,
> -                                             pos_out, count, flags);
> -       return ret;
> -}
> -
>  static loff_t nfs4_file_llseek(struct file *filep, loff_t offset, int whence)
>  {
>         loff_t ret;
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..87bf9efd7f71 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1358,58 +1358,6 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
>  }
>  #endif
>
> -/**
> - * generic_copy_file_range - copy data between two files
> - * @file_in:   file structure to read from
> - * @pos_in:    file offset to read from
> - * @file_out:  file structure to write data to
> - * @pos_out:   file offset to write data to
> - * @len:       amount of data to copy
> - * @flags:     copy flags
> - *
> - * This is a generic filesystem helper to copy data from one file to another.
> - * It has no constraints on the source or destination file owners - the files
> - * can belong to different superblocks and different filesystem types. Short
> - * copies are allowed.
> - *
> - * This should be called from the @file_out filesystem, as per the
> - * ->copy_file_range() method.
> - *
> - * Returns the number of bytes copied or a negative error indicating the
> - * failure.
> - */
> -
> -ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> -                               struct file *file_out, loff_t pos_out,
> -                               size_t len, unsigned int flags)
> -{
> -       return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> -                               len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> -}
> -EXPORT_SYMBOL(generic_copy_file_range);
> -
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                 struct file *file_out, loff_t pos_out,
> -                                 size_t len, unsigned int flags)
> -{
> -       /*
> -        * Although we now allow filesystems to handle cross sb copy, passing
> -        * a file of the wrong filesystem type to filesystem driver can result
> -        * in an attempt to dereference the wrong type of ->private_data, so
> -        * avoid doing that until we really have a good reason.  NFS defines
> -        * several different file_system_type structures, but they all end up
> -        * using the same ->copy_file_range() function pointer.
> -        */
> -       if (file_out->f_op->copy_file_range &&
> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -               return file_out->f_op->copy_file_range(file_in, pos_in,
> -                                                      file_out, pos_out,
> -                                                      len, flags);
> -
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);

Please do not remove the big comment above - it is there for a reason.

The case of !file_out->f_op->copy_file_range should return -EOPNOTSUPP
because the outcome of -EXDEV for copy to/from the same fs is confusing.

Either leave this helper and only remove generic_copy_file_range() or
open code the same logic (including comment) in the caller.

> -}
> -
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1474,6 +1422,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  {
>         ssize_t ret;
>
> +       /*
> +        * Allow the copy only if the filesystems for file_in and file_out are
> +        * the same, and copy_file_range is implemented.
> +        */

This comment is wrong. See the big fat comment above to understand why.
Also this check is in the wrong place because it misses the case of
file_in->f_op->remap_file_range && !file_out->f_op->copy_file_range

As I wrote above either leave the helper do_copy_file_range() or open
code it in its current location.

> +       if (!file_out->f_op->copy_file_range ||
> +           (file_out->f_op->copy_file_range != file_in->f_op->copy_file_range))
> +               return -EXDEV;
> +
>         if (flags != 0)
>                 return -EINVAL;
>
> @@ -1513,8 +1469,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                 }
>         }
>
> -       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                               flags);
> +       ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +                                             file_out, pos_out,
> +                                             len, flags);
>         WARN_ON_ONCE(ret == -EOPNOTSUPP);

Please remove this line.
filesystem ops can now return -EOPNOTSUPP.

Thanks,
Amir.

Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Mon, Feb 15, 2021 at 2:21 PM Luis Henriques <lhenriques@suse.de> wrote:
>>
>> Luis Henriques <lhenriques@suse.de> writes:
>>
>> > Amir Goldstein <amir73il@gmail.com> writes:
>> >
>> >> On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques <lhenriques@suse.de> wrote:
>> > ...
>> >>> Sure, I just wanted to point out that *maybe* there are other options than
>> >>> simply reverting that commit :-)
>> >>>
>> >>> Something like the patch below (completely untested!) should revert to the
>> >>> old behaviour in filesystems that don't implement the CFR syscall.
>> >>>
>> >>> Cheers,
>> >>> --
>> >>> Luis
>> >>>
>> >>> diff --git a/fs/read_write.c b/fs/read_write.c
>> >>> index 75f764b43418..bf5dccc43cc9 100644
>> >>> --- a/fs/read_write.c
>> >>> +++ b/fs/read_write.c
>> >>> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>> >>>                                                        file_out, pos_out,
>> >>>                                                        len, flags);
>> >>>
>> >>> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> >>> -                                      flags);
>> >>> +       if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> >>> +               return -EXDEV;
>> >>> +       else
>> >>> +               generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> >>> +                                       flags);
>> >>>  }
>> >>>
>> >>
>> >> Which kernel is this patch based on?
>> >
>> > It was v5.11-rc7.
>> >
>> >> At this point, I am with Dave and Darrick on not falling back to
>> >> generic_copy_file_range() at all.
>> >>
>> >> We do not have proof of any workload that benefits from it and the
>> >> above patch does not protect from a wierd use case of trying to copy a file
>> >> from sysfs to sysfs.
>> >>
>> >
>> > Ok, cool.  I can post a new patch doing just that.  I guess that function
>> > do_copy_file_range() can be dropped in that case.
>> >
>> >> I am indecisive about what should be done with generic_copy_file_range()
>> >> called as fallback from within filesystems.
>> >>
>> >> I think the wise choice is to not do the fallback in any case, but this is up
>> >> to the specific filesystem maintainers to decide.
>> >
>> > I see what you mean.  You're suggesting to have userspace handle all the
>> > -EOPNOTSUPP and -EXDEV errors.  Would you rather have a patch that also
>> > removes all the calls to generic_copy_file_range() function?  And that
>> > function can also be deleted too, of course.
>>
>> Here's a first stab at this patch.  Hopefully I didn't forgot anything
>> here.  Let me know if you prefer the more conservative approach, i.e. not
>> touching any of the filesystems and let them use generic_copy_file_range.
>>
>
> I'm fine with this one (modulu my comment below).
> CC'ing fuse/cifs/nfs maintainers.
> Though I don't think the FS maintainers should mind removing the fallback.
> It was added by "us" (64bf5ff58dff "vfs: no fallback for ->copy_file_range()")

Thanks for your review, Amir.  I'll be posting v2 shortly.

Cheers,
-- 
Luis


>> Once everyone agrees on the final solution, I can follow-up with the
>> manpages update.
>>
>> Cheers,
>> --
>> Luis
>>
>> From e1b37e80b12601d56f792bd19377d3e5208188ef Mon Sep 17 00:00:00 2001
>> From: Luis Henriques <lhenriques@suse.de>
>> Date: Fri, 12 Feb 2021 18:03:23 +0000
>> Subject: [PATCH] vfs: prevent copy_file_range to copy across devices
>>
>> Nicolas Boichat reported an issue when trying to use the copy_file_range
>> syscall on a tracefs file.  It failed silently because the file content is
>> generated on-the-fly (reporting a size of zero) and copy_file_range needs
>> to know in advance how much data is present.
>>
>> This commit effectively reverts 5dae222a5ff0 ("vfs: allow copy_file_range to
>> copy across devices").  Now the copy is done only if the filesystems for source
>> and destination files are the same and they implement this syscall.
>
> This paragraph is not true and confusing.
> This is not a revert and it does not revert the important part of cross-fs copy
> for which the original commit was for.
> Either rephrase this paragraph or remove it.
>
>>
>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
>
> Please add a Link: to this discussion in lore.
>
>> Cc: Nicolas Boichat <drinkcat@chromium.org>
>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> ---
>>  fs/ceph/file.c     | 21 +++------------
>>  fs/cifs/cifsfs.c   |  3 ---
>>  fs/fuse/file.c     | 21 +++------------
>>  fs/nfs/nfs4file.c  | 20 +++-----------
>>  fs/read_write.c    | 65 ++++++++--------------------------------------
>>  include/linux/fs.h |  3 ---
>>  6 files changed, 20 insertions(+), 113 deletions(-)
>>
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index 209535d5b8d3..639bd7bfaea9 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -2261,9 +2261,9 @@ static ssize_t ceph_do_objects_copy(struct ceph_inode_info *src_ci, u64 *src_off
>>         return bytes;
>>  }
>>
>> -static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> -                                     struct file *dst_file, loff_t dst_off,
>> -                                     size_t len, unsigned int flags)
>> +static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> +                                   struct file *dst_file, loff_t dst_off,
>> +                                   size_t len, unsigned int flags)
>>  {
>>         struct inode *src_inode = file_inode(src_file);
>>         struct inode *dst_inode = file_inode(dst_file);
>> @@ -2456,21 +2456,6 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
>>         return ret;
>>  }
>>
>> -static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
>> -                                   struct file *dst_file, loff_t dst_off,
>> -                                   size_t len, unsigned int flags)
>> -{
>> -       ssize_t ret;
>> -
>> -       ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
>> -                                    len, flags);
>> -
>> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> -               ret = generic_copy_file_range(src_file, src_off, dst_file,
>> -                                             dst_off, len, flags);
>> -       return ret;
>> -}
>> -
>>  const struct file_operations ceph_file_fops = {
>>         .open = ceph_open,
>>         .release = ceph_release,
>> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
>> index e46da536ed33..8b869cc67443 100644
>> --- a/fs/cifs/cifsfs.c
>> +++ b/fs/cifs/cifsfs.c
>> @@ -1229,9 +1229,6 @@ static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off,
>>                                         len, flags);
>>         free_xid(xid);
>>
>> -       if (rc == -EOPNOTSUPP || rc == -EXDEV)
>> -               rc = generic_copy_file_range(src_file, off, dst_file,
>> -                                            destoff, len, flags);
>>         return rc;
>>  }
>>
>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>> index 8cccecb55fb8..0dd703278e49 100644
>> --- a/fs/fuse/file.c
>> +++ b/fs/fuse/file.c
>> @@ -3330,9 +3330,9 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
>>         return err;
>>  }
>>
>> -static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>> -                                     struct file *file_out, loff_t pos_out,
>> -                                     size_t len, unsigned int flags)
>> +static ssize_t fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>> +                                   struct file *file_out, loff_t pos_out,
>> +                                   size_t len, unsigned int flags)
>>  {
>>         struct fuse_file *ff_in = file_in->private_data;
>>         struct fuse_file *ff_out = file_out->private_data;
>> @@ -3439,21 +3439,6 @@ static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
>>         return err;
>>  }
>>
>> -static ssize_t fuse_copy_file_range(struct file *src_file, loff_t src_off,
>> -                                   struct file *dst_file, loff_t dst_off,
>> -                                   size_t len, unsigned int flags)
>> -{
>> -       ssize_t ret;
>> -
>> -       ret = __fuse_copy_file_range(src_file, src_off, dst_file, dst_off,
>> -                                    len, flags);
>> -
>> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> -               ret = generic_copy_file_range(src_file, src_off, dst_file,
>> -                                             dst_off, len, flags);
>> -       return ret;
>> -}
>> -
>>  static const struct file_operations fuse_file_operations = {
>>         .llseek         = fuse_file_llseek,
>>         .read_iter      = fuse_file_read_iter,
>> diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
>> index 57b3821d975a..60998209e310 100644
>> --- a/fs/nfs/nfs4file.c
>> +++ b/fs/nfs/nfs4file.c
>> @@ -133,9 +133,9 @@ nfs4_file_flush(struct file *file, fl_owner_t id)
>>  }
>>
>>  #ifdef CONFIG_NFS_V4_2
>> -static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> -                                     struct file *file_out, loff_t pos_out,
>> -                                     size_t count, unsigned int flags)
>> +static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> +                                   struct file *file_out, loff_t pos_out,
>> +                                   size_t count, unsigned int flags)
>>  {
>>         struct nfs42_copy_notify_res *cn_resp = NULL;
>>         struct nl4_server *nss = NULL;
>> @@ -189,20 +189,6 @@ static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>>         return ret;
>>  }
>>
>> -static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
>> -                                   struct file *file_out, loff_t pos_out,
>> -                                   size_t count, unsigned int flags)
>> -{
>> -       ssize_t ret;
>> -
>> -       ret = __nfs4_copy_file_range(file_in, pos_in, file_out, pos_out, count,
>> -                                    flags);
>> -       if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> -               ret = generic_copy_file_range(file_in, pos_in, file_out,
>> -                                             pos_out, count, flags);
>> -       return ret;
>> -}
>> -
>>  static loff_t nfs4_file_llseek(struct file *filep, loff_t offset, int whence)
>>  {
>>         loff_t ret;
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..87bf9efd7f71 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1358,58 +1358,6 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
>>  }
>>  #endif
>>
>> -/**
>> - * generic_copy_file_range - copy data between two files
>> - * @file_in:   file structure to read from
>> - * @pos_in:    file offset to read from
>> - * @file_out:  file structure to write data to
>> - * @pos_out:   file offset to write data to
>> - * @len:       amount of data to copy
>> - * @flags:     copy flags
>> - *
>> - * This is a generic filesystem helper to copy data from one file to another.
>> - * It has no constraints on the source or destination file owners - the files
>> - * can belong to different superblocks and different filesystem types. Short
>> - * copies are allowed.
>> - *
>> - * This should be called from the @file_out filesystem, as per the
>> - * ->copy_file_range() method.
>> - *
>> - * Returns the number of bytes copied or a negative error indicating the
>> - * failure.
>> - */
>> -
>> -ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>> -                               struct file *file_out, loff_t pos_out,
>> -                               size_t len, unsigned int flags)
>> -{
>> -       return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
>> -                               len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
>> -}
>> -EXPORT_SYMBOL(generic_copy_file_range);
>> -
>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>> -                                 struct file *file_out, loff_t pos_out,
>> -                                 size_t len, unsigned int flags)
>> -{
>> -       /*
>> -        * Although we now allow filesystems to handle cross sb copy, passing
>> -        * a file of the wrong filesystem type to filesystem driver can result
>> -        * in an attempt to dereference the wrong type of ->private_data, so
>> -        * avoid doing that until we really have a good reason.  NFS defines
>> -        * several different file_system_type structures, but they all end up
>> -        * using the same ->copy_file_range() function pointer.
>> -        */
>> -       if (file_out->f_op->copy_file_range &&
>> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
>> -               return file_out->f_op->copy_file_range(file_in, pos_in,
>> -                                                      file_out, pos_out,
>> -                                                      len, flags);
>> -
>> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> -                                      flags);
>
> Please do not remove the big comment above - it is there for a reason.
>
> The case of !file_out->f_op->copy_file_range should return -EOPNOTSUPP
> because the outcome of -EXDEV for copy to/from the same fs is confusing.
>
> Either leave this helper and only remove generic_copy_file_range() or
> open code the same logic (including comment) in the caller.
>
>> -}
>> -
>>  /*
>>   * Performs necessary checks before doing a file copy
>>   *
>> @@ -1474,6 +1422,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>>  {
>>         ssize_t ret;
>>
>> +       /*
>> +        * Allow the copy only if the filesystems for file_in and file_out are
>> +        * the same, and copy_file_range is implemented.
>> +        */
>
> This comment is wrong. See the big fat comment above to understand why.
> Also this check is in the wrong place because it misses the case of
> file_in->f_op->remap_file_range && !file_out->f_op->copy_file_range
>
> As I wrote above either leave the helper do_copy_file_range() or open
> code it in its current location.
>
>> +       if (!file_out->f_op->copy_file_range ||
>> +           (file_out->f_op->copy_file_range != file_in->f_op->copy_file_range))
>> +               return -EXDEV;
>> +
>>         if (flags != 0)
>>                 return -EINVAL;
>>
>> @@ -1513,8 +1469,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>>                 }
>>         }
>>
>> -       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>> -                               flags);
>> +       ret = file_out->f_op->copy_file_range(file_in, pos_in,
>> +                                             file_out, pos_out,
>> +                                             len, flags);
>>         WARN_ON_ONCE(ret == -EOPNOTSUPP);
>
> Please remove this line.
> filesystem ops can now return -EOPNOTSUPP.
>
> Thanks,
> Amir.

[PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Nicolas Boichat reported an issue when trying to use the copy_file_range
syscall on a tracefs file.  It failed silently because the file content is
generated on-the-fly (reporting a size of zero) and copy_file_range needs
to know in advance how much data is present.

This commit restores the cross-fs restrictions that existed prior to
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") and
removes generic_copy_file_range() calls from ceph, cifs, fuse, and nfs.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Cc: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/ceph/file.c     | 21 +++-----------------
 fs/cifs/cifsfs.c   |  3 ---
 fs/fuse/file.c     | 21 +++-----------------
 fs/nfs/nfs4file.c  | 20 +++----------------
 fs/read_write.c    | 49 ++++++++++------------------------------------
 include/linux/fs.h |  3 ---
 6 files changed, 19 insertions(+), 98 deletions(-)

diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 209535d5b8d3..639bd7bfaea9 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@ -2261,9 +2261,9 @@ static ssize_t ceph_do_objects_copy(struct ceph_inode_info *src_ci, u64 *src_off
 	return bytes;
 }
 
-static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
-				      struct file *dst_file, loff_t dst_off,
-				      size_t len, unsigned int flags)
+static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
+				    struct file *dst_file, loff_t dst_off,
+				    size_t len, unsigned int flags)
 {
 	struct inode *src_inode = file_inode(src_file);
 	struct inode *dst_inode = file_inode(dst_file);
@@ -2456,21 +2456,6 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off,
 	return ret;
 }
 
-static ssize_t ceph_copy_file_range(struct file *src_file, loff_t src_off,
-				    struct file *dst_file, loff_t dst_off,
-				    size_t len, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
-				     len, flags);
-
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(src_file, src_off, dst_file,
-					      dst_off, len, flags);
-	return ret;
-}
-
 const struct file_operations ceph_file_fops = {
 	.open = ceph_open,
 	.release = ceph_release,
diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index ab883e84e116..7aa3d20f21c0 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -1229,9 +1229,6 @@ static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off,
 					len, flags);
 	free_xid(xid);
 
-	if (rc == -EOPNOTSUPP || rc == -EXDEV)
-		rc = generic_copy_file_range(src_file, off, dst_file,
-					     destoff, len, flags);
 	return rc;
 }
 
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 8cccecb55fb8..0dd703278e49 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -3330,9 +3330,9 @@ static long fuse_file_fallocate(struct file *file, int mode, loff_t offset,
 	return err;
 }
 
-static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
-				      struct file *file_out, loff_t pos_out,
-				      size_t len, unsigned int flags)
+static ssize_t fuse_copy_file_range(struct file *file_in, loff_t pos_in,
+				    struct file *file_out, loff_t pos_out,
+				    size_t len, unsigned int flags)
 {
 	struct fuse_file *ff_in = file_in->private_data;
 	struct fuse_file *ff_out = file_out->private_data;
@@ -3439,21 +3439,6 @@ static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos_in,
 	return err;
 }
 
-static ssize_t fuse_copy_file_range(struct file *src_file, loff_t src_off,
-				    struct file *dst_file, loff_t dst_off,
-				    size_t len, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __fuse_copy_file_range(src_file, src_off, dst_file, dst_off,
-				     len, flags);
-
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(src_file, src_off, dst_file,
-					      dst_off, len, flags);
-	return ret;
-}
-
 static const struct file_operations fuse_file_operations = {
 	.llseek		= fuse_file_llseek,
 	.read_iter	= fuse_file_read_iter,
diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index 57b3821d975a..60998209e310 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -133,9 +133,9 @@ nfs4_file_flush(struct file *file, fl_owner_t id)
 }
 
 #ifdef CONFIG_NFS_V4_2
-static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
-				      struct file *file_out, loff_t pos_out,
-				      size_t count, unsigned int flags)
+static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
+				    struct file *file_out, loff_t pos_out,
+				    size_t count, unsigned int flags)
 {
 	struct nfs42_copy_notify_res *cn_resp = NULL;
 	struct nl4_server *nss = NULL;
@@ -189,20 +189,6 @@ static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
 	return ret;
 }
 
-static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
-				    struct file *file_out, loff_t pos_out,
-				    size_t count, unsigned int flags)
-{
-	ssize_t ret;
-
-	ret = __nfs4_copy_file_range(file_in, pos_in, file_out, pos_out, count,
-				     flags);
-	if (ret == -EOPNOTSUPP || ret == -EXDEV)
-		ret = generic_copy_file_range(file_in, pos_in, file_out,
-					      pos_out, count, flags);
-	return ret;
-}
-
 static loff_t nfs4_file_llseek(struct file *filep, loff_t offset, int whence)
 {
 	loff_t ret;
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..b217cd62ae0d 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1358,40 +1358,12 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
 }
 #endif
 
-/**
- * generic_copy_file_range - copy data between two files
- * @file_in:	file structure to read from
- * @pos_in:	file offset to read from
- * @file_out:	file structure to write data to
- * @pos_out:	file offset to write data to
- * @len:	amount of data to copy
- * @flags:	copy flags
- *
- * This is a generic filesystem helper to copy data from one file to another.
- * It has no constraints on the source or destination file owners - the files
- * can belong to different superblocks and different filesystem types. Short
- * copies are allowed.
- *
- * This should be called from the @file_out filesystem, as per the
- * ->copy_file_range() method.
- *
- * Returns the number of bytes copied or a negative error indicating the
- * failure.
- */
-
-ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
-				struct file *file_out, loff_t pos_out,
-				size_t len, unsigned int flags)
-{
-	return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
-				len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
-}
-EXPORT_SYMBOL(generic_copy_file_range);
-
 static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
 				  struct file *file_out, loff_t pos_out,
 				  size_t len, unsigned int flags)
 {
+	ssize_t ret = -EXDEV;
+
 	/*
 	 * Although we now allow filesystems to handle cross sb copy, passing
 	 * a file of the wrong filesystem type to filesystem driver can result
@@ -1400,14 +1372,14 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
 	 * several different file_system_type structures, but they all end up
 	 * using the same ->copy_file_range() function pointer.
 	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
+	if (!file_out->f_op->copy_file_range)
+		ret = -EOPNOTSUPP;
+	else if (file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
+		ret = file_out->f_op->copy_file_range(file_in, pos_in,
+						      file_out, pos_out,
+						      len, flags);
 
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
+	return ret;
 }
 
 /*
@@ -1514,8 +1486,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 	}
 
 	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+				 flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index fd47deea7c17..3aaf627be409 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1910,9 +1910,6 @@ extern ssize_t vfs_read(struct file *, char __user *, size_t, loff_t *);
 extern ssize_t vfs_write(struct file *, const char __user *, size_t, loff_t *);
 extern ssize_t vfs_copy_file_range(struct file *, loff_t , struct file *,
 				   loff_t, size_t, unsigned int);
-extern ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
-				       struct file *file_out, loff_t pos_out,
-				       size_t len, unsigned int flags);
 extern int generic_remap_file_range_prep(struct file *file_in, loff_t pos_in,
 					 struct file *file_out, loff_t pos_out,
 					 loff_t *count,

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Trond Myklebust]

On Mon, 2021-02-15 at 15:43 +0000, Luis Henriques wrote:
> Nicolas Boichat reported an issue when trying to use the
> copy_file_range
> syscall on a tracefs file.  It failed silently because the file
> content is
> generated on-the-fly (reporting a size of zero) and copy_file_range
> needs
> to know in advance how much data is present.

That explanation makes no sense whatsoever. copy_file_range is a non-
atomic operation and so the file can change while being copied. Any
determination of 'how much data is present' that is made in advance
would therefore be a flaw in the copy process being used (i.e.
do_splice_direct()). Does sendfile() also 'issue' in the same way?


-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Nicolas Boichat reported an issue when trying to use the copy_file_range
> syscall on a tracefs file.  It failed silently because the file content is
> generated on-the-fly (reporting a size of zero) and copy_file_range needs
> to know in advance how much data is present.
>
> This commit restores the cross-fs restrictions that existed prior to
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") and
> removes generic_copy_file_range() calls from ceph, cifs, fuse, and nfs.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>

Code looks ok.
You may add:

Reviewed-by: Amir Goldstein <amir73il@gmail.com>

I agree with Trond that the first paragraph of the commit message could
be improved.
The purpose of this change is to fix the change of behavior that
caused the regression.

Before v5.3, behavior was -EXDEV and userspace could fallback to read.
After v5.3, behavior is zero size copy.

It does not matter so much what makes sense for CFR to do in this
case (generic cross-fs copy).  What matters is that nobody asked for
this change and that it caused problems.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Trond Myklebust]

On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <lhenriques@suse.de>
> wrote:
> > 
> > Nicolas Boichat reported an issue when trying to use the
> > copy_file_range
> > syscall on a tracefs file.  It failed silently because the file
> > content is
> > generated on-the-fly (reporting a size of zero) and copy_file_range
> > needs
> > to know in advance how much data is present.
> > 
> > This commit restores the cross-fs restrictions that existed prior
> > to
> > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > and
> > removes generic_copy_file_range() calls from ceph, cifs, fuse, and
> > nfs.
> > 
> > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > devices")
> > Link: 
> > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > Cc: Nicolas Boichat <drinkcat@chromium.org>
> > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> 
> Code looks ok.
> You may add:
> 
> Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> 
> I agree with Trond that the first paragraph of the commit message
> could
> be improved.
> The purpose of this change is to fix the change of behavior that
> caused the regression.
> 
> Before v5.3, behavior was -EXDEV and userspace could fallback to
> read.
> After v5.3, behavior is zero size copy.
> 
> It does not matter so much what makes sense for CFR to do in this
> case (generic cross-fs copy).  What matters is that nobody asked for
> this change and that it caused problems.
> 

No. I'm saying that this patch should be NACKed unless there is a real
explanation for why we give crap about this tracefs corner case and why
it can't be fixed.

There are plenty of reasons why copy offload across filesystems makes
sense, and particularly when you're doing NAS. Clone just doesn't cut
it when it comes to disaster recovery (whereas backup to a different
storage unit does). If the client has to do the copy, then you're
effectively doubling the load on the server, and you're adding
potentially unnecessary network traffic (or at the very least you are
doubling that traffic).

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <lhenriques@suse.de>
> > wrote:
> > >
> > > Nicolas Boichat reported an issue when trying to use the
> > > copy_file_range
> > > syscall on a tracefs file.  It failed silently because the file
> > > content is
> > > generated on-the-fly (reporting a size of zero) and copy_file_range
> > > needs
> > > to know in advance how much data is present.
> > >
> > > This commit restores the cross-fs restrictions that existed prior
> > > to
> > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > > and
> > > removes generic_copy_file_range() calls from ceph, cifs, fuse, and
> > > nfs.
> > >
> > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > devices")
> > > Link:
> > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > > Cc: Nicolas Boichat <drinkcat@chromium.org>
> > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> >
> > Code looks ok.
> > You may add:
> >
> > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> >
> > I agree with Trond that the first paragraph of the commit message
> > could
> > be improved.
> > The purpose of this change is to fix the change of behavior that
> > caused the regression.
> >
> > Before v5.3, behavior was -EXDEV and userspace could fallback to
> > read.
> > After v5.3, behavior is zero size copy.
> >
> > It does not matter so much what makes sense for CFR to do in this
> > case (generic cross-fs copy).  What matters is that nobody asked for
> > this change and that it caused problems.
> >
>
> No. I'm saying that this patch should be NACKed unless there is a real
> explanation for why we give crap about this tracefs corner case and why
> it can't be fixed.
>
> There are plenty of reasons why copy offload across filesystems makes
> sense, and particularly when you're doing NAS. Clone just doesn't cut
> it when it comes to disaster recovery (whereas backup to a different
> storage unit does). If the client has to do the copy, then you're
> effectively doubling the load on the server, and you're adding
> potentially unnecessary network traffic (or at the very least you are
> doubling that traffic).
>

I don't understand the use case you are describing.

Which filesystem types are you talking about for source and target
of copy_file_range()?

To be clear, the original change was done to support NFS/CIFS server-side
copy and those should not be affected by this change.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Trond Myklebust]

On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
> On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
> trondmy@hammerspace.com> wrote:
> > 
> > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
> > > lhenriques@suse.de>
> > > wrote:
> > > > 
> > > > Nicolas Boichat reported an issue when trying to use the
> > > > copy_file_range
> > > > syscall on a tracefs file.  It failed silently because the file
> > > > content is
> > > > generated on-the-fly (reporting a size of zero) and
> > > > copy_file_range
> > > > needs
> > > > to know in advance how much data is present.
> > > > 
> > > > This commit restores the cross-fs restrictions that existed
> > > > prior
> > > > to
> > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > > devices")
> > > > and
> > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
> > > > and
> > > > nfs.
> > > > 
> > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > > devices")
> > > > Link:
> > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
> > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > > 
> > > Code looks ok.
> > > You may add:
> > > 
> > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> > > 
> > > I agree with Trond that the first paragraph of the commit message
> > > could
> > > be improved.
> > > The purpose of this change is to fix the change of behavior that
> > > caused the regression.
> > > 
> > > Before v5.3, behavior was -EXDEV and userspace could fallback to
> > > read.
> > > After v5.3, behavior is zero size copy.
> > > 
> > > It does not matter so much what makes sense for CFR to do in this
> > > case (generic cross-fs copy).  What matters is that nobody asked
> > > for
> > > this change and that it caused problems.
> > > 
> > 
> > No. I'm saying that this patch should be NACKed unless there is a
> > real
> > explanation for why we give crap about this tracefs corner case and
> > why
> > it can't be fixed.
> > 
> > There are plenty of reasons why copy offload across filesystems
> > makes
> > sense, and particularly when you're doing NAS. Clone just doesn't
> > cut
> > it when it comes to disaster recovery (whereas backup to a
> > different
> > storage unit does). If the client has to do the copy, then you're
> > effectively doubling the load on the server, and you're adding
> > potentially unnecessary network traffic (or at the very least you
> > are
> > doubling that traffic).
> > 
> 
> I don't understand the use case you are describing.
> 
> Which filesystem types are you talking about for source and target
> of copy_file_range()?
> 
> To be clear, the original change was done to support NFS/CIFS server-
> side
> copy and those should not be affected by this change.
> 

That is incorrect: 

ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
*dst,
 u64 dst_pos, u64 count)
{

 /*
 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
 * thread and client rpc slot. The choice of 4MB is somewhat
 * arbitrary. We might instead base this on r/wsize, or make it
 * tunable, or use a time instead of a byte limit, or implement
 * asynchronous copy. In theory a client could also recognize a
 * limit like this and pipeline multiple COPY requests.
 */
 count = min_t(u64, count, 1 << 22);
 return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
}

You are now explicitly changing the behaviour of knfsd when the source
and destination filesystem differ.

For one thing, you are disallowing the NFSv4.2 copy offload use case of
copying from a local filesystem to a remote NFS server. However you are
also disallowing the copy from, say, an XFS formatted partition to an
ext4 partition.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
> > trondmy@hammerspace.com> wrote:
> > >
> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
> > > > lhenriques@suse.de>
> > > > wrote:
> > > > >
> > > > > Nicolas Boichat reported an issue when trying to use the
> > > > > copy_file_range
> > > > > syscall on a tracefs file.  It failed silently because the file
> > > > > content is
> > > > > generated on-the-fly (reporting a size of zero) and
> > > > > copy_file_range
> > > > > needs
> > > > > to know in advance how much data is present.
> > > > >
> > > > > This commit restores the cross-fs restrictions that existed
> > > > > prior
> > > > > to
> > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > > > devices")
> > > > > and
> > > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
> > > > > and
> > > > > nfs.
> > > > >
> > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > > > devices")
> > > > > Link:
> > > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
> > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > > >
> > > > Code looks ok.
> > > > You may add:
> > > >
> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> > > >
> > > > I agree with Trond that the first paragraph of the commit message
> > > > could
> > > > be improved.
> > > > The purpose of this change is to fix the change of behavior that
> > > > caused the regression.
> > > >
> > > > Before v5.3, behavior was -EXDEV and userspace could fallback to
> > > > read.
> > > > After v5.3, behavior is zero size copy.
> > > >
> > > > It does not matter so much what makes sense for CFR to do in this
> > > > case (generic cross-fs copy).  What matters is that nobody asked
> > > > for
> > > > this change and that it caused problems.
> > > >
> > >
> > > No. I'm saying that this patch should be NACKed unless there is a
> > > real
> > > explanation for why we give crap about this tracefs corner case and
> > > why
> > > it can't be fixed.
> > >
> > > There are plenty of reasons why copy offload across filesystems
> > > makes
> > > sense, and particularly when you're doing NAS. Clone just doesn't
> > > cut
> > > it when it comes to disaster recovery (whereas backup to a
> > > different
> > > storage unit does). If the client has to do the copy, then you're
> > > effectively doubling the load on the server, and you're adding
> > > potentially unnecessary network traffic (or at the very least you
> > > are
> > > doubling that traffic).
> > >
> >
> > I don't understand the use case you are describing.
> >
> > Which filesystem types are you talking about for source and target
> > of copy_file_range()?
> >
> > To be clear, the original change was done to support NFS/CIFS server-
> > side
> > copy and those should not be affected by this change.
> >
>
> That is incorrect:
>
> ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
> *dst,
>  u64 dst_pos, u64 count)
> {
>
>  /*
>  * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>  * thread and client rpc slot. The choice of 4MB is somewhat
>  * arbitrary. We might instead base this on r/wsize, or make it
>  * tunable, or use a time instead of a byte limit, or implement
>  * asynchronous copy. In theory a client could also recognize a
>  * limit like this and pipeline multiple COPY requests.
>  */
>  count = min_t(u64, count, 1 << 22);
>  return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> }
>
> You are now explicitly changing the behaviour of knfsd when the source
> and destination filesystem differ.
>
> For one thing, you are disallowing the NFSv4.2 copy offload use case of
> copying from a local filesystem to a remote NFS server. However you are
> also disallowing the copy from, say, an XFS formatted partition to an
> ext4 partition.
>

Got it.
This is easy to solve with a flag COPY_FILE_SPLICE (or something)
that is internal to kernel users.

FWIW, you may want to look at the loop in ovl_copy_up_data()
for improvements to nfsd_copy_file_range().

We can move the check out to copy_file_range syscall:

        if (flags != 0)
                return -EINVAL;

Leave the fallback from all filesystems and check for the
COPY_FILE_SPLICE flag inside generic_copy_file_range().

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Steve French]

On Mon, Feb 15, 2021 at 10:11 AM Trond Myklebust
<trondmy@hammerspace.com> wrote:
>
> On Mon, 2021-02-15 at 15:43 +0000, Luis Henriques wrote:
> > Nicolas Boichat reported an issue when trying to use the
> > copy_file_range
> > syscall on a tracefs file.  It failed silently because the file
> > content is
> > generated on-the-fly (reporting a size of zero) and copy_file_range
> > needs
> > to know in advance how much data is present.
>
> That explanation makes no sense whatsoever. copy_file_range is a non-
> atomic operation and so the file can change while being copied. Any
> determination of 'how much data is present' that is made in advance
> would therefore be a flaw in the copy process being used (i.e.
> do_splice_direct()). Does sendfile() also 'issue' in the same way?

I agree that the explanation of the tracefs problem motivating this
patch doesn't make sense.


-- 
Thanks,

Steve

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
>>
>> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
>> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
>> > trondmy@hammerspace.com> wrote:
>> > >
>> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
>> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
>> > > > lhenriques@suse.de>
>> > > > wrote:
>> > > > >
>> > > > > Nicolas Boichat reported an issue when trying to use the
>> > > > > copy_file_range
>> > > > > syscall on a tracefs file.  It failed silently because the file
>> > > > > content is
>> > > > > generated on-the-fly (reporting a size of zero) and
>> > > > > copy_file_range
>> > > > > needs
>> > > > > to know in advance how much data is present.
>> > > > >
>> > > > > This commit restores the cross-fs restrictions that existed
>> > > > > prior
>> > > > > to
>> > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> > > > > devices")
>> > > > > and
>> > > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
>> > > > > and
>> > > > > nfs.
>> > > > >
>> > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> > > > > devices")
>> > > > > Link:
>> > > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
>> > > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
>> > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> > > >
>> > > > Code looks ok.
>> > > > You may add:
>> > > >
>> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
>> > > >
>> > > > I agree with Trond that the first paragraph of the commit message
>> > > > could
>> > > > be improved.
>> > > > The purpose of this change is to fix the change of behavior that
>> > > > caused the regression.
>> > > >
>> > > > Before v5.3, behavior was -EXDEV and userspace could fallback to
>> > > > read.
>> > > > After v5.3, behavior is zero size copy.
>> > > >
>> > > > It does not matter so much what makes sense for CFR to do in this
>> > > > case (generic cross-fs copy).  What matters is that nobody asked
>> > > > for
>> > > > this change and that it caused problems.
>> > > >
>> > >
>> > > No. I'm saying that this patch should be NACKed unless there is a
>> > > real
>> > > explanation for why we give crap about this tracefs corner case and
>> > > why
>> > > it can't be fixed.
>> > >
>> > > There are plenty of reasons why copy offload across filesystems
>> > > makes
>> > > sense, and particularly when you're doing NAS. Clone just doesn't
>> > > cut
>> > > it when it comes to disaster recovery (whereas backup to a
>> > > different
>> > > storage unit does). If the client has to do the copy, then you're
>> > > effectively doubling the load on the server, and you're adding
>> > > potentially unnecessary network traffic (or at the very least you
>> > > are
>> > > doubling that traffic).
>> > >
>> >
>> > I don't understand the use case you are describing.
>> >
>> > Which filesystem types are you talking about for source and target
>> > of copy_file_range()?
>> >
>> > To be clear, the original change was done to support NFS/CIFS server-
>> > side
>> > copy and those should not be affected by this change.
>> >
>>
>> That is incorrect:
>>
>> ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
>> *dst,
>>  u64 dst_pos, u64 count)
>> {
>>
>>  /*
>>  * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>>  * thread and client rpc slot. The choice of 4MB is somewhat
>>  * arbitrary. We might instead base this on r/wsize, or make it
>>  * tunable, or use a time instead of a byte limit, or implement
>>  * asynchronous copy. In theory a client could also recognize a
>>  * limit like this and pipeline multiple COPY requests.
>>  */
>>  count = min_t(u64, count, 1 << 22);
>>  return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>> }
>>
>> You are now explicitly changing the behaviour of knfsd when the source
>> and destination filesystem differ.
>>
>> For one thing, you are disallowing the NFSv4.2 copy offload use case of
>> copying from a local filesystem to a remote NFS server. However you are
>> also disallowing the copy from, say, an XFS formatted partition to an
>> ext4 partition.
>>
>
> Got it.

Ugh.  And I guess overlayfs may have a similar problem.

> This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> is internal to kernel users.
>
> FWIW, you may want to look at the loop in ovl_copy_up_data()
> for improvements to nfsd_copy_file_range().
>
> We can move the check out to copy_file_range syscall:
>
>         if (flags != 0)
>                 return -EINVAL;
>
> Leave the fallback from all filesystems and check for the
> COPY_FILE_SPLICE flag inside generic_copy_file_range().

Ok, the diff bellow is just to make sure I understood your suggestion.

The patch will also need to:

 - change nfs and overlayfs calls to vfs_copy_file_range() so that they
   use the new flag.

 - check flags in generic_copy_file_checks() to make sure only valid flags
   are used (COPY_FILE_SPLICE at the moment).

Also, where should this flag be defined?  include/uapi/linux/fs.h?

Cheers,
-- 
Luis

diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..341d315d2a96 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 				struct file *file_out, loff_t pos_out,
 				size_t len, unsigned int flags)
 {
+	if (!(flags & COPY_FILE_SPLICE)) {
+		if (!file_out->f_op->copy_file_range)
+			return -EOPNOTSUPP;
+		else if (file_out->f_op->copy_file_range !=
+			 file_in->f_op->copy_file_range)
+			return -EXDEV;
+	}
 	return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
 				len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
 }
@@ -1474,9 +1481,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 {
 	ssize_t ret;
 
-	if (flags != 0)
-		return -EINVAL;
-
 	ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
 				       flags);
 	if (unlikely(ret))

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[gregkh]

On Tue, Feb 16, 2021 at 11:17:34AM +0000, Luis Henriques wrote:
> Amir Goldstein <amir73il@gmail.com> writes:
> 
> > On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
> >>
> >> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
> >> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
> >> > trondmy@hammerspace.com> wrote:
> >> > >
> >> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> >> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
> >> > > > lhenriques@suse.de>
> >> > > > wrote:
> >> > > > >
> >> > > > > Nicolas Boichat reported an issue when trying to use the
> >> > > > > copy_file_range
> >> > > > > syscall on a tracefs file.  It failed silently because the file
> >> > > > > content is
> >> > > > > generated on-the-fly (reporting a size of zero) and
> >> > > > > copy_file_range
> >> > > > > needs
> >> > > > > to know in advance how much data is present.
> >> > > > >
> >> > > > > This commit restores the cross-fs restrictions that existed
> >> > > > > prior
> >> > > > > to
> >> > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >> > > > > devices")
> >> > > > > and
> >> > > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
> >> > > > > and
> >> > > > > nfs.
> >> > > > >
> >> > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >> > > > > devices")
> >> > > > > Link:
> >> > > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> >> > > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
> >> > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> >> > > >
> >> > > > Code looks ok.
> >> > > > You may add:
> >> > > >
> >> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> >> > > >
> >> > > > I agree with Trond that the first paragraph of the commit message
> >> > > > could
> >> > > > be improved.
> >> > > > The purpose of this change is to fix the change of behavior that
> >> > > > caused the regression.
> >> > > >
> >> > > > Before v5.3, behavior was -EXDEV and userspace could fallback to
> >> > > > read.
> >> > > > After v5.3, behavior is zero size copy.
> >> > > >
> >> > > > It does not matter so much what makes sense for CFR to do in this
> >> > > > case (generic cross-fs copy).  What matters is that nobody asked
> >> > > > for
> >> > > > this change and that it caused problems.
> >> > > >
> >> > >
> >> > > No. I'm saying that this patch should be NACKed unless there is a
> >> > > real
> >> > > explanation for why we give crap about this tracefs corner case and
> >> > > why
> >> > > it can't be fixed.
> >> > >
> >> > > There are plenty of reasons why copy offload across filesystems
> >> > > makes
> >> > > sense, and particularly when you're doing NAS. Clone just doesn't
> >> > > cut
> >> > > it when it comes to disaster recovery (whereas backup to a
> >> > > different
> >> > > storage unit does). If the client has to do the copy, then you're
> >> > > effectively doubling the load on the server, and you're adding
> >> > > potentially unnecessary network traffic (or at the very least you
> >> > > are
> >> > > doubling that traffic).
> >> > >
> >> >
> >> > I don't understand the use case you are describing.
> >> >
> >> > Which filesystem types are you talking about for source and target
> >> > of copy_file_range()?
> >> >
> >> > To be clear, the original change was done to support NFS/CIFS server-
> >> > side
> >> > copy and those should not be affected by this change.
> >> >
> >>
> >> That is incorrect:
> >>
> >> ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
> >> *dst,
> >>  u64 dst_pos, u64 count)
> >> {
> >>
> >>  /*
> >>  * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> >>  * thread and client rpc slot. The choice of 4MB is somewhat
> >>  * arbitrary. We might instead base this on r/wsize, or make it
> >>  * tunable, or use a time instead of a byte limit, or implement
> >>  * asynchronous copy. In theory a client could also recognize a
> >>  * limit like this and pipeline multiple COPY requests.
> >>  */
> >>  count = min_t(u64, count, 1 << 22);
> >>  return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >> }
> >>
> >> You are now explicitly changing the behaviour of knfsd when the source
> >> and destination filesystem differ.
> >>
> >> For one thing, you are disallowing the NFSv4.2 copy offload use case of
> >> copying from a local filesystem to a remote NFS server. However you are
> >> also disallowing the copy from, say, an XFS formatted partition to an
> >> ext4 partition.
> >>
> >
> > Got it.
> 
> Ugh.  And I guess overlayfs may have a similar problem.
> 
> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > is internal to kernel users.
> >
> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > for improvements to nfsd_copy_file_range().
> >
> > We can move the check out to copy_file_range syscall:
> >
> >         if (flags != 0)
> >                 return -EINVAL;
> >
> > Leave the fallback from all filesystems and check for the
> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> 
> Ok, the diff bellow is just to make sure I understood your suggestion.
> 
> The patch will also need to:
> 
>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>    use the new flag.
> 
>  - check flags in generic_copy_file_checks() to make sure only valid flags
>    are used (COPY_FILE_SPLICE at the moment).
> 
> Also, where should this flag be defined?  include/uapi/linux/fs.h?

Why would userspace want/need this flag?

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> writes:

> On Tue, Feb 16, 2021 at 11:17:34AM +0000, Luis Henriques wrote:
>> Amir Goldstein <amir73il@gmail.com> writes:
>> 
>> > On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
>> >>
>> >> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
>> >> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
>> >> > trondmy@hammerspace.com> wrote:
>> >> > >
>> >> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
>> >> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
>> >> > > > lhenriques@suse.de>
>> >> > > > wrote:
>> >> > > > >
>> >> > > > > Nicolas Boichat reported an issue when trying to use the
>> >> > > > > copy_file_range
>> >> > > > > syscall on a tracefs file.  It failed silently because the file
>> >> > > > > content is
>> >> > > > > generated on-the-fly (reporting a size of zero) and
>> >> > > > > copy_file_range
>> >> > > > > needs
>> >> > > > > to know in advance how much data is present.
>> >> > > > >
>> >> > > > > This commit restores the cross-fs restrictions that existed
>> >> > > > > prior
>> >> > > > > to
>> >> > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> >> > > > > devices")
>> >> > > > > and
>> >> > > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
>> >> > > > > and
>> >> > > > > nfs.
>> >> > > > >
>> >> > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> >> > > > > devices")
>> >> > > > > Link:
>> >> > > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
>> >> > > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
>> >> > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> >> > > >
>> >> > > > Code looks ok.
>> >> > > > You may add:
>> >> > > >
>> >> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
>> >> > > >
>> >> > > > I agree with Trond that the first paragraph of the commit message
>> >> > > > could
>> >> > > > be improved.
>> >> > > > The purpose of this change is to fix the change of behavior that
>> >> > > > caused the regression.
>> >> > > >
>> >> > > > Before v5.3, behavior was -EXDEV and userspace could fallback to
>> >> > > > read.
>> >> > > > After v5.3, behavior is zero size copy.
>> >> > > >
>> >> > > > It does not matter so much what makes sense for CFR to do in this
>> >> > > > case (generic cross-fs copy).  What matters is that nobody asked
>> >> > > > for
>> >> > > > this change and that it caused problems.
>> >> > > >
>> >> > >
>> >> > > No. I'm saying that this patch should be NACKed unless there is a
>> >> > > real
>> >> > > explanation for why we give crap about this tracefs corner case and
>> >> > > why
>> >> > > it can't be fixed.
>> >> > >
>> >> > > There are plenty of reasons why copy offload across filesystems
>> >> > > makes
>> >> > > sense, and particularly when you're doing NAS. Clone just doesn't
>> >> > > cut
>> >> > > it when it comes to disaster recovery (whereas backup to a
>> >> > > different
>> >> > > storage unit does). If the client has to do the copy, then you're
>> >> > > effectively doubling the load on the server, and you're adding
>> >> > > potentially unnecessary network traffic (or at the very least you
>> >> > > are
>> >> > > doubling that traffic).
>> >> > >
>> >> >
>> >> > I don't understand the use case you are describing.
>> >> >
>> >> > Which filesystem types are you talking about for source and target
>> >> > of copy_file_range()?
>> >> >
>> >> > To be clear, the original change was done to support NFS/CIFS server-
>> >> > side
>> >> > copy and those should not be affected by this change.
>> >> >
>> >>
>> >> That is incorrect:
>> >>
>> >> ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
>> >> *dst,
>> >>  u64 dst_pos, u64 count)
>> >> {
>> >>
>> >>  /*
>> >>  * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>> >>  * thread and client rpc slot. The choice of 4MB is somewhat
>> >>  * arbitrary. We might instead base this on r/wsize, or make it
>> >>  * tunable, or use a time instead of a byte limit, or implement
>> >>  * asynchronous copy. In theory a client could also recognize a
>> >>  * limit like this and pipeline multiple COPY requests.
>> >>  */
>> >>  count = min_t(u64, count, 1 << 22);
>> >>  return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>> >> }
>> >>
>> >> You are now explicitly changing the behaviour of knfsd when the source
>> >> and destination filesystem differ.
>> >>
>> >> For one thing, you are disallowing the NFSv4.2 copy offload use case of
>> >> copying from a local filesystem to a remote NFS server. However you are
>> >> also disallowing the copy from, say, an XFS formatted partition to an
>> >> ext4 partition.
>> >>
>> >
>> > Got it.
>> 
>> Ugh.  And I guess overlayfs may have a similar problem.
>> 
>> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
>> > is internal to kernel users.
>> >
>> > FWIW, you may want to look at the loop in ovl_copy_up_data()
>> > for improvements to nfsd_copy_file_range().
>> >
>> > We can move the check out to copy_file_range syscall:
>> >
>> >         if (flags != 0)
>> >                 return -EINVAL;
>> >
>> > Leave the fallback from all filesystems and check for the
>> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
>> 
>> Ok, the diff bellow is just to make sure I understood your suggestion.
>> 
>> The patch will also need to:
>> 
>>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>>    use the new flag.
>> 
>>  - check flags in generic_copy_file_checks() to make sure only valid flags
>>    are used (COPY_FILE_SPLICE at the moment).
>> 
>> Also, where should this flag be defined?  include/uapi/linux/fs.h?
>
> Why would userspace want/need this flag?

In fact, my question sort of implied yours :-)

What I wanted to know was whether we would like to allow userspace to
_explicitly_ revert to the current behaviour (i.e. use the flag to allow
cross-fs copies) or to continue to return -EINVAL to userspace if flags
are != 0 (in which case this check would need to move to the syscall
definition).

Cheers,
-- 
Luis

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Greg KH]

On Tue, Feb 16, 2021 at 12:01:16PM +0000, Luis Henriques wrote:
> "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> writes:
> 
> > On Tue, Feb 16, 2021 at 11:17:34AM +0000, Luis Henriques wrote:
> >> Amir Goldstein <amir73il@gmail.com> writes:
> >> 
> >> > On Mon, Feb 15, 2021 at 8:57 PM Trond Myklebust <trondmy@hammerspace.com> wrote:
> >> >>
> >> >> On Mon, 2021-02-15 at 19:24 +0200, Amir Goldstein wrote:
> >> >> > On Mon, Feb 15, 2021 at 6:53 PM Trond Myklebust <
> >> >> > trondmy@hammerspace.com> wrote:
> >> >> > >
> >> >> > > On Mon, 2021-02-15 at 18:34 +0200, Amir Goldstein wrote:
> >> >> > > > On Mon, Feb 15, 2021 at 5:42 PM Luis Henriques <
> >> >> > > > lhenriques@suse.de>
> >> >> > > > wrote:
> >> >> > > > >
> >> >> > > > > Nicolas Boichat reported an issue when trying to use the
> >> >> > > > > copy_file_range
> >> >> > > > > syscall on a tracefs file.  It failed silently because the file
> >> >> > > > > content is
> >> >> > > > > generated on-the-fly (reporting a size of zero) and
> >> >> > > > > copy_file_range
> >> >> > > > > needs
> >> >> > > > > to know in advance how much data is present.
> >> >> > > > >
> >> >> > > > > This commit restores the cross-fs restrictions that existed
> >> >> > > > > prior
> >> >> > > > > to
> >> >> > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >> >> > > > > devices")
> >> >> > > > > and
> >> >> > > > > removes generic_copy_file_range() calls from ceph, cifs, fuse,
> >> >> > > > > and
> >> >> > > > > nfs.
> >> >> > > > >
> >> >> > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >> >> > > > > devices")
> >> >> > > > > Link:
> >> >> > > > > https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> >> >> > > > > Cc: Nicolas Boichat <drinkcat@chromium.org>
> >> >> > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> >> >> > > >
> >> >> > > > Code looks ok.
> >> >> > > > You may add:
> >> >> > > >
> >> >> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> >> >> > > >
> >> >> > > > I agree with Trond that the first paragraph of the commit message
> >> >> > > > could
> >> >> > > > be improved.
> >> >> > > > The purpose of this change is to fix the change of behavior that
> >> >> > > > caused the regression.
> >> >> > > >
> >> >> > > > Before v5.3, behavior was -EXDEV and userspace could fallback to
> >> >> > > > read.
> >> >> > > > After v5.3, behavior is zero size copy.
> >> >> > > >
> >> >> > > > It does not matter so much what makes sense for CFR to do in this
> >> >> > > > case (generic cross-fs copy).  What matters is that nobody asked
> >> >> > > > for
> >> >> > > > this change and that it caused problems.
> >> >> > > >
> >> >> > >
> >> >> > > No. I'm saying that this patch should be NACKed unless there is a
> >> >> > > real
> >> >> > > explanation for why we give crap about this tracefs corner case and
> >> >> > > why
> >> >> > > it can't be fixed.
> >> >> > >
> >> >> > > There are plenty of reasons why copy offload across filesystems
> >> >> > > makes
> >> >> > > sense, and particularly when you're doing NAS. Clone just doesn't
> >> >> > > cut
> >> >> > > it when it comes to disaster recovery (whereas backup to a
> >> >> > > different
> >> >> > > storage unit does). If the client has to do the copy, then you're
> >> >> > > effectively doubling the load on the server, and you're adding
> >> >> > > potentially unnecessary network traffic (or at the very least you
> >> >> > > are
> >> >> > > doubling that traffic).
> >> >> > >
> >> >> >
> >> >> > I don't understand the use case you are describing.
> >> >> >
> >> >> > Which filesystem types are you talking about for source and target
> >> >> > of copy_file_range()?
> >> >> >
> >> >> > To be clear, the original change was done to support NFS/CIFS server-
> >> >> > side
> >> >> > copy and those should not be affected by this change.
> >> >> >
> >> >>
> >> >> That is incorrect:
> >> >>
> >> >> ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file
> >> >> *dst,
> >> >>  u64 dst_pos, u64 count)
> >> >> {
> >> >>
> >> >>  /*
> >> >>  * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> >> >>  * thread and client rpc slot. The choice of 4MB is somewhat
> >> >>  * arbitrary. We might instead base this on r/wsize, or make it
> >> >>  * tunable, or use a time instead of a byte limit, or implement
> >> >>  * asynchronous copy. In theory a client could also recognize a
> >> >>  * limit like this and pipeline multiple COPY requests.
> >> >>  */
> >> >>  count = min_t(u64, count, 1 << 22);
> >> >>  return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >> >> }
> >> >>
> >> >> You are now explicitly changing the behaviour of knfsd when the source
> >> >> and destination filesystem differ.
> >> >>
> >> >> For one thing, you are disallowing the NFSv4.2 copy offload use case of
> >> >> copying from a local filesystem to a remote NFS server. However you are
> >> >> also disallowing the copy from, say, an XFS formatted partition to an
> >> >> ext4 partition.
> >> >>
> >> >
> >> > Got it.
> >> 
> >> Ugh.  And I guess overlayfs may have a similar problem.
> >> 
> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> >> > is internal to kernel users.
> >> >
> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> >> > for improvements to nfsd_copy_file_range().
> >> >
> >> > We can move the check out to copy_file_range syscall:
> >> >
> >> >         if (flags != 0)
> >> >                 return -EINVAL;
> >> >
> >> > Leave the fallback from all filesystems and check for the
> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> >> 
> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> >> 
> >> The patch will also need to:
> >> 
> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> >>    use the new flag.
> >> 
> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> >>    are used (COPY_FILE_SPLICE at the moment).
> >> 
> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> >
> > Why would userspace want/need this flag?
> 
> In fact, my question sort of implied yours :-)
> 
> What I wanted to know was whether we would like to allow userspace to
> _explicitly_ revert to the current behaviour (i.e. use the flag to allow
> cross-fs copies) or to continue to return -EINVAL to userspace if flags
> are != 0 (in which case this check would need to move to the syscall
> definition).

No, don't try to mess with userspace that way, the kernel should "just
work".  Well, in this case "work as best as it can, not always
successful...", it's an odd syscall.

thanks,

greg k-h

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

> Ugh.  And I guess overlayfs may have a similar problem.

Not exactly.
Generally speaking, overlayfs should call vfs_copy_file_range()
with the flags it got from layer above, so if called from nfsd it
will allow cross fs copy and when called from syscall it won't.

There are some corner cases where overlayfs could benefit from
COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
let's leave those for now. Just leave overlayfs code as is.

>
> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > is internal to kernel users.
> >
> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > for improvements to nfsd_copy_file_range().
> >
> > We can move the check out to copy_file_range syscall:
> >
> >         if (flags != 0)
> >                 return -EINVAL;
> >
> > Leave the fallback from all filesystems and check for the
> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
>
> Ok, the diff bellow is just to make sure I understood your suggestion.
>
> The patch will also need to:
>
>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>    use the new flag.
>
>  - check flags in generic_copy_file_checks() to make sure only valid flags
>    are used (COPY_FILE_SPLICE at the moment).
>
> Also, where should this flag be defined?  include/uapi/linux/fs.h?

Grep for REMAP_FILE_
Same header file, same Documentation rst file.

>
> Cheers,
> --
> Luis
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..341d315d2a96 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>                                 struct file *file_out, loff_t pos_out,
>                                 size_t len, unsigned int flags)
>  {
> +       if (!(flags & COPY_FILE_SPLICE)) {
> +               if (!file_out->f_op->copy_file_range)
> +                       return -EOPNOTSUPP;
> +               else if (file_out->f_op->copy_file_range !=
> +                        file_in->f_op->copy_file_range)
> +                       return -EXDEV;
> +       }

That looks strange, because you are duplicating the logic in
do_copy_file_range(). Maybe better:

if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
        return -EINVAL;
if (flags & COPY_FILE_SPLICE)
       return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
                                 len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
if (!file_out->f_op->copy_file_range)
        return -EOPNOTSUPP;
return -EXDEV;

>  }
> @@ -1474,9 +1481,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  {
>         ssize_t ret;
>
> -       if (flags != 0)
> -               return -EINVAL;
> -

This needs to move to the beginning of SYSCALL_DEFINE6(copy_file_range,...

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

>> Ugh.  And I guess overlayfs may have a similar problem.
>
> Not exactly.
> Generally speaking, overlayfs should call vfs_copy_file_range()
> with the flags it got from layer above, so if called from nfsd it
> will allow cross fs copy and when called from syscall it won't.
>
> There are some corner cases where overlayfs could benefit from
> COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> let's leave those for now. Just leave overlayfs code as is.

Got it, thanks for clarifying.

>> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
>> > is internal to kernel users.
>> >
>> > FWIW, you may want to look at the loop in ovl_copy_up_data()
>> > for improvements to nfsd_copy_file_range().
>> >
>> > We can move the check out to copy_file_range syscall:
>> >
>> >         if (flags != 0)
>> >                 return -EINVAL;
>> >
>> > Leave the fallback from all filesystems and check for the
>> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
>>
>> Ok, the diff bellow is just to make sure I understood your suggestion.
>>
>> The patch will also need to:
>>
>>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>>    use the new flag.
>>
>>  - check flags in generic_copy_file_checks() to make sure only valid flags
>>    are used (COPY_FILE_SPLICE at the moment).
>>
>> Also, where should this flag be defined?  include/uapi/linux/fs.h?
>
> Grep for REMAP_FILE_
> Same header file, same Documentation rst file.
>
>>
>> Cheers,
>> --
>> Luis
>>
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..341d315d2a96 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>>                                 struct file *file_out, loff_t pos_out,
>>                                 size_t len, unsigned int flags)
>>  {
>> +       if (!(flags & COPY_FILE_SPLICE)) {
>> +               if (!file_out->f_op->copy_file_range)
>> +                       return -EOPNOTSUPP;
>> +               else if (file_out->f_op->copy_file_range !=
>> +                        file_in->f_op->copy_file_range)
>> +                       return -EXDEV;
>> +       }
>
> That looks strange, because you are duplicating the logic in
> do_copy_file_range(). Maybe better:
>
> if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
>         return -EINVAL;
> if (flags & COPY_FILE_SPLICE)
>        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
>                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);

My initial reasoning for duplicating the logic in do_copy_file_range() was
to allow the generic_copy_file_range() callers to be left unmodified and
allow the filesystems to default to this implementation.

With this change, I guess that the calls to generic_copy_file_range() from
the different filesystems can be dropped, as in my initial patch, as they
will always get -EINVAL.  The other option would be to set the
COPY_FILE_SPLICE flag in those calls, but that would get us back to the
problem we're trying to solve.

> if (!file_out->f_op->copy_file_range)
>         return -EOPNOTSUPP;
> return -EXDEV;
>
>>  }
>> @@ -1474,9 +1481,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>>  {
>>         ssize_t ret;
>>
>> -       if (flags != 0)
>> -               return -EINVAL;
>> -
>
> This needs to move to the beginning of SYSCALL_DEFINE6(copy_file_range,...

Yep, I didn't included that change in my diff as I wasn't sure if you'd
like to have the flag visible in userspace.

Anyway, thanks for your patience!

Cheers,
-- 
Luis

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Amir Goldstein <amir73il@gmail.com> writes:
>
> >> Ugh.  And I guess overlayfs may have a similar problem.
> >
> > Not exactly.
> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > with the flags it got from layer above, so if called from nfsd it
> > will allow cross fs copy and when called from syscall it won't.
> >
> > There are some corner cases where overlayfs could benefit from
> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > let's leave those for now. Just leave overlayfs code as is.
>
> Got it, thanks for clarifying.
>
> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> >> > is internal to kernel users.
> >> >
> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> >> > for improvements to nfsd_copy_file_range().
> >> >
> >> > We can move the check out to copy_file_range syscall:
> >> >
> >> >         if (flags != 0)
> >> >                 return -EINVAL;
> >> >
> >> > Leave the fallback from all filesystems and check for the
> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> >>
> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> >>
> >> The patch will also need to:
> >>
> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> >>    use the new flag.
> >>
> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> >>    are used (COPY_FILE_SPLICE at the moment).
> >>
> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> >
> > Grep for REMAP_FILE_
> > Same header file, same Documentation rst file.
> >
> >>
> >> Cheers,
> >> --
> >> Luis
> >>
> >> diff --git a/fs/read_write.c b/fs/read_write.c
> >> index 75f764b43418..341d315d2a96 100644
> >> --- a/fs/read_write.c
> >> +++ b/fs/read_write.c
> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> >>                                 struct file *file_out, loff_t pos_out,
> >>                                 size_t len, unsigned int flags)
> >>  {
> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> >> +               if (!file_out->f_op->copy_file_range)
> >> +                       return -EOPNOTSUPP;
> >> +               else if (file_out->f_op->copy_file_range !=
> >> +                        file_in->f_op->copy_file_range)
> >> +                       return -EXDEV;
> >> +       }
> >
> > That looks strange, because you are duplicating the logic in
> > do_copy_file_range(). Maybe better:
> >
> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> >         return -EINVAL;
> > if (flags & COPY_FILE_SPLICE)
> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
>
> My initial reasoning for duplicating the logic in do_copy_file_range() was
> to allow the generic_copy_file_range() callers to be left unmodified and
> allow the filesystems to default to this implementation.
>
> With this change, I guess that the calls to generic_copy_file_range() from
> the different filesystems can be dropped, as in my initial patch, as they
> will always get -EINVAL.  The other option would be to set the
> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> problem we're trying to solve.

I don't understand the problem.

What exactly is wrong with the code I suggested?
Why should any filesystem be changed?

Maybe I am missing something.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Andreas Dilger]

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

On Feb 16, 2021, at 6:51 AM, Amir Goldstein <amir73il@gmail.com> wrote:
>> 
>>> This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
>>> is internal to kernel users.
>>> 
>>> FWIW, you may want to look at the loop in ovl_copy_up_data()
>>> for improvements to nfsd_copy_file_range().
>>> 
>>> We can move the check out to copy_file_range syscall:
>>> 
>>>        if (flags != 0)
>>>                return -EINVAL;
>>> 
>>> Leave the fallback from all filesystems and check for the
>>> COPY_FILE_SPLICE flag inside generic_copy_file_range().
>> 
>> Ok, the diff bellow is just to make sure I understood your suggestion.
>> 
>> The patch will also need to:
>> 
>> - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>>   use the new flag.
>> 
>> - check flags in generic_copy_file_checks() to make sure only valid flags
>>   are used (COPY_FILE_SPLICE at the moment).
>> 
>> Also, where should this flag be defined?  include/uapi/linux/fs.h?
>> 
>> Cheers,
>> --
>> Luis
>> 
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..341d315d2a96 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>>                                struct file *file_out, loff_t pos_out,
>>                                size_t len, unsigned int flags)
>> {
>> +       if (!(flags & COPY_FILE_SPLICE)) {
>> +               if (!file_out->f_op->copy_file_range)
>> +                       return -EOPNOTSUPP;
>> +               else if (file_out->f_op->copy_file_range !=
>> +                        file_in->f_op->copy_file_range)
>> +                       return -EXDEV;
>> +       }
> 
> That looks strange, because you are duplicating the logic in
> do_copy_file_range(). Maybe better:
> 
> if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
>        return -EINVAL;
> if (flags & COPY_FILE_SPLICE)
>       return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
>                                 len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> if (!file_out->f_op->copy_file_range)
>        return -EOPNOTSUPP;
> return -EXDEV;

This shouldn't return -EINVAL to userspace if the flag is not set.

That implies there *is* some valid way for userspace to call this
function, which is AFAICS not possible if COPY_FILE_SPLICE is only
available to in-kernel callers.  Instead, it should continue
to return -EOPNOTSUPP to userspace if copy_file_range() is not valid
for this combination of file descriptors, so that applications will
fall back to the non-CFR implementation.

The WARN_ON_ONCE(ret == -EOPNOTSUPP) in vfs_copy_file_range() would
also need to be removed if this will be triggered from userspace.


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
>>
>> Amir Goldstein <amir73il@gmail.com> writes:
>>
>> >> Ugh.  And I guess overlayfs may have a similar problem.
>> >
>> > Not exactly.
>> > Generally speaking, overlayfs should call vfs_copy_file_range()
>> > with the flags it got from layer above, so if called from nfsd it
>> > will allow cross fs copy and when called from syscall it won't.
>> >
>> > There are some corner cases where overlayfs could benefit from
>> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
>> > let's leave those for now. Just leave overlayfs code as is.
>>
>> Got it, thanks for clarifying.
>>
>> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
>> >> > is internal to kernel users.
>> >> >
>> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
>> >> > for improvements to nfsd_copy_file_range().
>> >> >
>> >> > We can move the check out to copy_file_range syscall:
>> >> >
>> >> >         if (flags != 0)
>> >> >                 return -EINVAL;
>> >> >
>> >> > Leave the fallback from all filesystems and check for the
>> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
>> >>
>> >> Ok, the diff bellow is just to make sure I understood your suggestion.
>> >>
>> >> The patch will also need to:
>> >>
>> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
>> >>    use the new flag.
>> >>
>> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
>> >>    are used (COPY_FILE_SPLICE at the moment).
>> >>
>> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
>> >
>> > Grep for REMAP_FILE_
>> > Same header file, same Documentation rst file.
>> >
>> >>
>> >> Cheers,
>> >> --
>> >> Luis
>> >>
>> >> diff --git a/fs/read_write.c b/fs/read_write.c
>> >> index 75f764b43418..341d315d2a96 100644
>> >> --- a/fs/read_write.c
>> >> +++ b/fs/read_write.c
>> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>> >>                                 struct file *file_out, loff_t pos_out,
>> >>                                 size_t len, unsigned int flags)
>> >>  {
>> >> +       if (!(flags & COPY_FILE_SPLICE)) {
>> >> +               if (!file_out->f_op->copy_file_range)
>> >> +                       return -EOPNOTSUPP;
>> >> +               else if (file_out->f_op->copy_file_range !=
>> >> +                        file_in->f_op->copy_file_range)
>> >> +                       return -EXDEV;
>> >> +       }
>> >
>> > That looks strange, because you are duplicating the logic in
>> > do_copy_file_range(). Maybe better:
>> >
>> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
>> >         return -EINVAL;
>> > if (flags & COPY_FILE_SPLICE)
>> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
>> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
>>
>> My initial reasoning for duplicating the logic in do_copy_file_range() was
>> to allow the generic_copy_file_range() callers to be left unmodified and
>> allow the filesystems to default to this implementation.
>>
>> With this change, I guess that the calls to generic_copy_file_range() from
>> the different filesystems can be dropped, as in my initial patch, as they
>> will always get -EINVAL.  The other option would be to set the
>> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
>> problem we're trying to solve.
>
> I don't understand the problem.
>
> What exactly is wrong with the code I suggested?
> Why should any filesystem be changed?
>
> Maybe I am missing something.

Ok, I have to do a full brain reboot and start all over.

Before that, I picked the code you suggested and tested it.  I've mounted
a cephfs filesystem and used xfs_io to execute a 'copy_range' command
using /sys/kernel/debug/sched_features as source.  The result was a
0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
early exit in:

	if (len == 0)
		return 0;

'len' is set in generic_copy_file_checks().

This means that we're not solving the original problem anymore (probably
since v1 of this patch, haven't checked).

Also, re-reading Trond's emails, I read: "... also disallowing the copy
from, say, an XFS formatted partition to an ext4 partition".  Isn't that
*exactly* what we're trying to do here?  I.e. _prevent_ these copies from
happening so that tracefs files can't be CFR'ed?

/me stops now and waits to see if the morning brings some sun :-)

Cheers,
-- 
Luis

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Amir Goldstein <amir73il@gmail.com> writes:
>
> > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> >>
> >> Amir Goldstein <amir73il@gmail.com> writes:
> >>
> >> >> Ugh.  And I guess overlayfs may have a similar problem.
> >> >
> >> > Not exactly.
> >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> >> > with the flags it got from layer above, so if called from nfsd it
> >> > will allow cross fs copy and when called from syscall it won't.
> >> >
> >> > There are some corner cases where overlayfs could benefit from
> >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> >> > let's leave those for now. Just leave overlayfs code as is.
> >>
> >> Got it, thanks for clarifying.
> >>
> >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> >> >> > is internal to kernel users.
> >> >> >
> >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> >> >> > for improvements to nfsd_copy_file_range().
> >> >> >
> >> >> > We can move the check out to copy_file_range syscall:
> >> >> >
> >> >> >         if (flags != 0)
> >> >> >                 return -EINVAL;
> >> >> >
> >> >> > Leave the fallback from all filesystems and check for the
> >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> >> >>
> >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> >> >>
> >> >> The patch will also need to:
> >> >>
> >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> >> >>    use the new flag.
> >> >>
> >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> >> >>    are used (COPY_FILE_SPLICE at the moment).
> >> >>
> >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> >> >
> >> > Grep for REMAP_FILE_
> >> > Same header file, same Documentation rst file.
> >> >
> >> >>
> >> >> Cheers,
> >> >> --
> >> >> Luis
> >> >>
> >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> >> >> index 75f764b43418..341d315d2a96 100644
> >> >> --- a/fs/read_write.c
> >> >> +++ b/fs/read_write.c
> >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> >> >>                                 struct file *file_out, loff_t pos_out,
> >> >>                                 size_t len, unsigned int flags)
> >> >>  {
> >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> >> >> +               if (!file_out->f_op->copy_file_range)
> >> >> +                       return -EOPNOTSUPP;
> >> >> +               else if (file_out->f_op->copy_file_range !=
> >> >> +                        file_in->f_op->copy_file_range)
> >> >> +                       return -EXDEV;
> >> >> +       }
> >> >
> >> > That looks strange, because you are duplicating the logic in
> >> > do_copy_file_range(). Maybe better:
> >> >
> >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> >> >         return -EINVAL;
> >> > if (flags & COPY_FILE_SPLICE)
> >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> >>
> >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> >> to allow the generic_copy_file_range() callers to be left unmodified and
> >> allow the filesystems to default to this implementation.
> >>
> >> With this change, I guess that the calls to generic_copy_file_range() from
> >> the different filesystems can be dropped, as in my initial patch, as they
> >> will always get -EINVAL.  The other option would be to set the
> >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> >> problem we're trying to solve.
> >
> > I don't understand the problem.
> >
> > What exactly is wrong with the code I suggested?
> > Why should any filesystem be changed?
> >
> > Maybe I am missing something.
>
> Ok, I have to do a full brain reboot and start all over.
>
> Before that, I picked the code you suggested and tested it.  I've mounted
> a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> using /sys/kernel/debug/sched_features as source.  The result was a
> 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> early exit in:
>
>         if (len == 0)
>                 return 0;
>
> 'len' is set in generic_copy_file_checks().

Good point.. I guess we will need to do all the checks earlier in
generic_copy_file_checks() including the logic of:

        if (file_in->f_op->remap_file_range &&
            file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)


>
> This means that we're not solving the original problem anymore (probably
> since v1 of this patch, haven't checked).
>
> Also, re-reading Trond's emails, I read: "... also disallowing the copy
> from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> happening so that tracefs files can't be CFR'ed?
>

We want to address the report which means calls coming from
copy_file_range() syscall.

Trond's use case is vfs_copy_file_range() coming from nfsd.
When he writes about copy from XFS to ext4, he means an
NFS client is issuing server side copy (on same or different NFS mounts)
and the NFS server is executing nfsd_copy_file_range() on a source
file that happens to be on XFS and destination happens to be on ext4.

We can undo the copy_file_range() syscall change of behavior from
v5.3 without regressing the NFS use case.

We just need to be careful and look at all the affected code paths.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Anna Schumaker]

On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
> >
> > Amir Goldstein <amir73il@gmail.com> writes:
> >
> > > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> > >>
> > >> Amir Goldstein <amir73il@gmail.com> writes:
> > >>
> > >> >> Ugh.  And I guess overlayfs may have a similar problem.
> > >> >
> > >> > Not exactly.
> > >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > >> > with the flags it got from layer above, so if called from nfsd it
> > >> > will allow cross fs copy and when called from syscall it won't.
> > >> >
> > >> > There are some corner cases where overlayfs could benefit from
> > >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > >> > let's leave those for now. Just leave overlayfs code as is.
> > >>
> > >> Got it, thanks for clarifying.
> > >>
> > >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > >> >> > is internal to kernel users.
> > >> >> >
> > >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > >> >> > for improvements to nfsd_copy_file_range().
> > >> >> >
> > >> >> > We can move the check out to copy_file_range syscall:
> > >> >> >
> > >> >> >         if (flags != 0)
> > >> >> >                 return -EINVAL;
> > >> >> >
> > >> >> > Leave the fallback from all filesystems and check for the
> > >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> > >> >>
> > >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> > >> >>
> > >> >> The patch will also need to:
> > >> >>
> > >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> > >> >>    use the new flag.
> > >> >>
> > >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> > >> >>    are used (COPY_FILE_SPLICE at the moment).
> > >> >>
> > >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> > >> >
> > >> > Grep for REMAP_FILE_
> > >> > Same header file, same Documentation rst file.
> > >> >
> > >> >>
> > >> >> Cheers,
> > >> >> --
> > >> >> Luis
> > >> >>
> > >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> > >> >> index 75f764b43418..341d315d2a96 100644
> > >> >> --- a/fs/read_write.c
> > >> >> +++ b/fs/read_write.c
> > >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > >> >>                                 struct file *file_out, loff_t pos_out,
> > >> >>                                 size_t len, unsigned int flags)
> > >> >>  {
> > >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> > >> >> +               if (!file_out->f_op->copy_file_range)
> > >> >> +                       return -EOPNOTSUPP;
> > >> >> +               else if (file_out->f_op->copy_file_range !=
> > >> >> +                        file_in->f_op->copy_file_range)
> > >> >> +                       return -EXDEV;
> > >> >> +       }
> > >> >
> > >> > That looks strange, because you are duplicating the logic in
> > >> > do_copy_file_range(). Maybe better:
> > >> >
> > >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> > >> >         return -EINVAL;
> > >> > if (flags & COPY_FILE_SPLICE)
> > >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> > >>
> > >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> > >> to allow the generic_copy_file_range() callers to be left unmodified and
> > >> allow the filesystems to default to this implementation.
> > >>
> > >> With this change, I guess that the calls to generic_copy_file_range() from
> > >> the different filesystems can be dropped, as in my initial patch, as they
> > >> will always get -EINVAL.  The other option would be to set the
> > >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> > >> problem we're trying to solve.
> > >
> > > I don't understand the problem.
> > >
> > > What exactly is wrong with the code I suggested?
> > > Why should any filesystem be changed?
> > >
> > > Maybe I am missing something.
> >
> > Ok, I have to do a full brain reboot and start all over.
> >
> > Before that, I picked the code you suggested and tested it.  I've mounted
> > a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> > using /sys/kernel/debug/sched_features as source.  The result was a
> > 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> > early exit in:
> >
> >         if (len == 0)
> >                 return 0;
> >
> > 'len' is set in generic_copy_file_checks().
>
> Good point.. I guess we will need to do all the checks earlier in
> generic_copy_file_checks() including the logic of:
>
>         if (file_in->f_op->remap_file_range &&
>             file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)
>
>
> >
> > This means that we're not solving the original problem anymore (probably
> > since v1 of this patch, haven't checked).
> >
> > Also, re-reading Trond's emails, I read: "... also disallowing the copy
> > from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> > *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> > happening so that tracefs files can't be CFR'ed?
> >
>
> We want to address the report which means calls coming from
> copy_file_range() syscall.
>
> Trond's use case is vfs_copy_file_range() coming from nfsd.
> When he writes about copy from XFS to ext4, he means an
> NFS client is issuing server side copy (on same or different NFS mounts)
> and the NFS server is executing nfsd_copy_file_range() on a source
> file that happens to be on XFS and destination happens to be on ext4.

NFS also supports a server-to-server copy where the destination server
mounts the source server and reads the data to be copied. Please don't
break that either :)

Anna

>
> We can undo the copy_file_range() syscall change of behavior from
> v5.3 without regressing the NFS use case.
>
> We just need to be careful and look at all the affected code paths.
>
> Thanks,
> Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Steve French]

On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
<anna.schumaker@netapp.com> wrote:
>
> On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
> > >
> > > Amir Goldstein <amir73il@gmail.com> writes:
> > >
> > > > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > >>
> > > >> Amir Goldstein <amir73il@gmail.com> writes:
> > > >>
> > > >> >> Ugh.  And I guess overlayfs may have a similar problem.
> > > >> >
> > > >> > Not exactly.
> > > >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > > >> > with the flags it got from layer above, so if called from nfsd it
> > > >> > will allow cross fs copy and when called from syscall it won't.
> > > >> >
> > > >> > There are some corner cases where overlayfs could benefit from
> > > >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > > >> > let's leave those for now. Just leave overlayfs code as is.
> > > >>
> > > >> Got it, thanks for clarifying.
> > > >>
> > > >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > > >> >> > is internal to kernel users.
> > > >> >> >
> > > >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > > >> >> > for improvements to nfsd_copy_file_range().
> > > >> >> >
> > > >> >> > We can move the check out to copy_file_range syscall:
> > > >> >> >
> > > >> >> >         if (flags != 0)
> > > >> >> >                 return -EINVAL;
> > > >> >> >
> > > >> >> > Leave the fallback from all filesystems and check for the
> > > >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> > > >> >>
> > > >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> > > >> >>
> > > >> >> The patch will also need to:
> > > >> >>
> > > >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> > > >> >>    use the new flag.
> > > >> >>
> > > >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> > > >> >>    are used (COPY_FILE_SPLICE at the moment).
> > > >> >>
> > > >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> > > >> >
> > > >> > Grep for REMAP_FILE_
> > > >> > Same header file, same Documentation rst file.
> > > >> >
> > > >> >>
> > > >> >> Cheers,
> > > >> >> --
> > > >> >> Luis
> > > >> >>
> > > >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> > > >> >> index 75f764b43418..341d315d2a96 100644
> > > >> >> --- a/fs/read_write.c
> > > >> >> +++ b/fs/read_write.c
> > > >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > > >> >>                                 struct file *file_out, loff_t pos_out,
> > > >> >>                                 size_t len, unsigned int flags)
> > > >> >>  {
> > > >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> > > >> >> +               if (!file_out->f_op->copy_file_range)
> > > >> >> +                       return -EOPNOTSUPP;
> > > >> >> +               else if (file_out->f_op->copy_file_range !=
> > > >> >> +                        file_in->f_op->copy_file_range)
> > > >> >> +                       return -EXDEV;
> > > >> >> +       }
> > > >> >
> > > >> > That looks strange, because you are duplicating the logic in
> > > >> > do_copy_file_range(). Maybe better:
> > > >> >
> > > >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> > > >> >         return -EINVAL;
> > > >> > if (flags & COPY_FILE_SPLICE)
> > > >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > > >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> > > >>
> > > >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> > > >> to allow the generic_copy_file_range() callers to be left unmodified and
> > > >> allow the filesystems to default to this implementation.
> > > >>
> > > >> With this change, I guess that the calls to generic_copy_file_range() from
> > > >> the different filesystems can be dropped, as in my initial patch, as they
> > > >> will always get -EINVAL.  The other option would be to set the
> > > >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> > > >> problem we're trying to solve.
> > > >
> > > > I don't understand the problem.
> > > >
> > > > What exactly is wrong with the code I suggested?
> > > > Why should any filesystem be changed?
> > > >
> > > > Maybe I am missing something.
> > >
> > > Ok, I have to do a full brain reboot and start all over.
> > >
> > > Before that, I picked the code you suggested and tested it.  I've mounted
> > > a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> > > using /sys/kernel/debug/sched_features as source.  The result was a
> > > 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> > > early exit in:
> > >
> > >         if (len == 0)
> > >                 return 0;
> > >
> > > 'len' is set in generic_copy_file_checks().
> >
> > Good point.. I guess we will need to do all the checks earlier in
> > generic_copy_file_checks() including the logic of:
> >
> >         if (file_in->f_op->remap_file_range &&
> >             file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)
> >
> >
> > >
> > > This means that we're not solving the original problem anymore (probably
> > > since v1 of this patch, haven't checked).
> > >
> > > Also, re-reading Trond's emails, I read: "... also disallowing the copy
> > > from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> > > *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> > > happening so that tracefs files can't be CFR'ed?
> > >
> >
> > We want to address the report which means calls coming from
> > copy_file_range() syscall.
> >
> > Trond's use case is vfs_copy_file_range() coming from nfsd.
> > When he writes about copy from XFS to ext4, he means an
> > NFS client is issuing server side copy (on same or different NFS mounts)
> > and the NFS server is executing nfsd_copy_file_range() on a source
> > file that happens to be on XFS and destination happens to be on ext4.
>
> NFS also supports a server-to-server copy where the destination server
> mounts the source server and reads the data to be copied. Please don't
> break that either :)

This is a case we will eventually need to support for cifs (SMB3) as well.


-- 
Thanks,

Steve

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Tue, Feb 16, 2021 at 9:31 PM Steve French <smfrench@gmail.com> wrote:
>
> On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
> <anna.schumaker@netapp.com> wrote:
> >
> > On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > >
> > > > Amir Goldstein <amir73il@gmail.com> writes:
> > > >
> > > > > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > > >>
> > > > >> Amir Goldstein <amir73il@gmail.com> writes:
> > > > >>
> > > > >> >> Ugh.  And I guess overlayfs may have a similar problem.
> > > > >> >
> > > > >> > Not exactly.
> > > > >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > > > >> > with the flags it got from layer above, so if called from nfsd it
> > > > >> > will allow cross fs copy and when called from syscall it won't.
> > > > >> >
> > > > >> > There are some corner cases where overlayfs could benefit from
> > > > >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > > > >> > let's leave those for now. Just leave overlayfs code as is.
> > > > >>
> > > > >> Got it, thanks for clarifying.
> > > > >>
> > > > >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > > > >> >> > is internal to kernel users.
> > > > >> >> >
> > > > >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > > > >> >> > for improvements to nfsd_copy_file_range().
> > > > >> >> >
> > > > >> >> > We can move the check out to copy_file_range syscall:
> > > > >> >> >
> > > > >> >> >         if (flags != 0)
> > > > >> >> >                 return -EINVAL;
> > > > >> >> >
> > > > >> >> > Leave the fallback from all filesystems and check for the
> > > > >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> > > > >> >>
> > > > >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> > > > >> >>
> > > > >> >> The patch will also need to:
> > > > >> >>
> > > > >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> > > > >> >>    use the new flag.
> > > > >> >>
> > > > >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> > > > >> >>    are used (COPY_FILE_SPLICE at the moment).
> > > > >> >>
> > > > >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> > > > >> >
> > > > >> > Grep for REMAP_FILE_
> > > > >> > Same header file, same Documentation rst file.
> > > > >> >
> > > > >> >>
> > > > >> >> Cheers,
> > > > >> >> --
> > > > >> >> Luis
> > > > >> >>
> > > > >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> > > > >> >> index 75f764b43418..341d315d2a96 100644
> > > > >> >> --- a/fs/read_write.c
> > > > >> >> +++ b/fs/read_write.c
> > > > >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > > > >> >>                                 struct file *file_out, loff_t pos_out,
> > > > >> >>                                 size_t len, unsigned int flags)
> > > > >> >>  {
> > > > >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> > > > >> >> +               if (!file_out->f_op->copy_file_range)
> > > > >> >> +                       return -EOPNOTSUPP;
> > > > >> >> +               else if (file_out->f_op->copy_file_range !=
> > > > >> >> +                        file_in->f_op->copy_file_range)
> > > > >> >> +                       return -EXDEV;
> > > > >> >> +       }
> > > > >> >
> > > > >> > That looks strange, because you are duplicating the logic in
> > > > >> > do_copy_file_range(). Maybe better:
> > > > >> >
> > > > >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> > > > >> >         return -EINVAL;
> > > > >> > if (flags & COPY_FILE_SPLICE)
> > > > >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > > > >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> > > > >>
> > > > >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> > > > >> to allow the generic_copy_file_range() callers to be left unmodified and
> > > > >> allow the filesystems to default to this implementation.
> > > > >>
> > > > >> With this change, I guess that the calls to generic_copy_file_range() from
> > > > >> the different filesystems can be dropped, as in my initial patch, as they
> > > > >> will always get -EINVAL.  The other option would be to set the
> > > > >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> > > > >> problem we're trying to solve.
> > > > >
> > > > > I don't understand the problem.
> > > > >
> > > > > What exactly is wrong with the code I suggested?
> > > > > Why should any filesystem be changed?
> > > > >
> > > > > Maybe I am missing something.
> > > >
> > > > Ok, I have to do a full brain reboot and start all over.
> > > >
> > > > Before that, I picked the code you suggested and tested it.  I've mounted
> > > > a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> > > > using /sys/kernel/debug/sched_features as source.  The result was a
> > > > 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> > > > early exit in:
> > > >
> > > >         if (len == 0)
> > > >                 return 0;
> > > >
> > > > 'len' is set in generic_copy_file_checks().
> > >
> > > Good point.. I guess we will need to do all the checks earlier in
> > > generic_copy_file_checks() including the logic of:
> > >
> > >         if (file_in->f_op->remap_file_range &&
> > >             file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)
> > >
> > >
> > > >
> > > > This means that we're not solving the original problem anymore (probably
> > > > since v1 of this patch, haven't checked).
> > > >
> > > > Also, re-reading Trond's emails, I read: "... also disallowing the copy
> > > > from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> > > > *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> > > > happening so that tracefs files can't be CFR'ed?
> > > >
> > >
> > > We want to address the report which means calls coming from
> > > copy_file_range() syscall.
> > >
> > > Trond's use case is vfs_copy_file_range() coming from nfsd.
> > > When he writes about copy from XFS to ext4, he means an
> > > NFS client is issuing server side copy (on same or different NFS mounts)
> > > and the NFS server is executing nfsd_copy_file_range() on a source
> > > file that happens to be on XFS and destination happens to be on ext4.
> >
> > NFS also supports a server-to-server copy where the destination server
> > mounts the source server and reads the data to be copied. Please don't
> > break that either :)
>

As long as the copy is via nfsd_copy_file_range() and not from the syscall
it should not regress.

> This is a case we will eventually need to support for cifs (SMB3) as well.
>

samba already does server side copy very well without needing any support
from the kernel.

nfsd also doesn't *need* to use vfs_copy_file_range() it can use kernel APIs
like the loop in ovl_copy_up_data(). But it does, so we should not regress it.

samba/nfsd can try to use copy_file_range() and it will work if the
source/target
fs support it. Otherwise, the server can perfectly well do the copy via other
available interfaces, just like userspace copy tools.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Steve French]

On Tue, Feb 16, 2021 at 1:40 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Feb 16, 2021 at 9:31 PM Steve French <smfrench@gmail.com> wrote:
> >
> > On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
> > <anna.schumaker@netapp.com> wrote:
> > >
> > > On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > >
> > > > On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > > >
> > > > > Amir Goldstein <amir73il@gmail.com> writes:
> > > > >
> > > > > > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > > > >>
> > > > > >> Amir Goldstein <amir73il@gmail.com> writes:
> > > > > >>
> > > > > >> >> Ugh.  And I guess overlayfs may have a similar problem.
> > > > > >> >
> > > > > >> > Not exactly.
> > > > > >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > > > > >> > with the flags it got from layer above, so if called from nfsd it
> > > > > >> > will allow cross fs copy and when called from syscall it won't.
> > > > > >> >
> > > > > >> > There are some corner cases where overlayfs could benefit from
> > > > > >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > > > > >> > let's leave those for now. Just leave overlayfs code as is.
> > > > > >>
> > > > > >> Got it, thanks for clarifying.
> > > > > >>
> > > > > >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > > > > >> >> > is internal to kernel users.
> > > > > >> >> >
> > > > > >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > > > > >> >> > for improvements to nfsd_copy_file_range().
> > > > > >> >> >
> > > > > >> >> > We can move the check out to copy_file_range syscall:
> > > > > >> >> >
> > > > > >> >> >         if (flags != 0)
> > > > > >> >> >                 return -EINVAL;
> > > > > >> >> >
> > > > > >> >> > Leave the fallback from all filesystems and check for the
> > > > > >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> > > > > >> >>
> > > > > >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> > > > > >> >>
> > > > > >> >> The patch will also need to:
> > > > > >> >>
> > > > > >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> > > > > >> >>    use the new flag.
> > > > > >> >>
> > > > > >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> > > > > >> >>    are used (COPY_FILE_SPLICE at the moment).
> > > > > >> >>
> > > > > >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> > > > > >> >
> > > > > >> > Grep for REMAP_FILE_
> > > > > >> > Same header file, same Documentation rst file.
> > > > > >> >
> > > > > >> >>
> > > > > >> >> Cheers,
> > > > > >> >> --
> > > > > >> >> Luis
> > > > > >> >>
> > > > > >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> > > > > >> >> index 75f764b43418..341d315d2a96 100644
> > > > > >> >> --- a/fs/read_write.c
> > > > > >> >> +++ b/fs/read_write.c
> > > > > >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > > > > >> >>                                 struct file *file_out, loff_t pos_out,
> > > > > >> >>                                 size_t len, unsigned int flags)
> > > > > >> >>  {
> > > > > >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> > > > > >> >> +               if (!file_out->f_op->copy_file_range)
> > > > > >> >> +                       return -EOPNOTSUPP;
> > > > > >> >> +               else if (file_out->f_op->copy_file_range !=
> > > > > >> >> +                        file_in->f_op->copy_file_range)
> > > > > >> >> +                       return -EXDEV;
> > > > > >> >> +       }
> > > > > >> >
> > > > > >> > That looks strange, because you are duplicating the logic in
> > > > > >> > do_copy_file_range(). Maybe better:
> > > > > >> >
> > > > > >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> > > > > >> >         return -EINVAL;
> > > > > >> > if (flags & COPY_FILE_SPLICE)
> > > > > >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > > > > >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> > > > > >>
> > > > > >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> > > > > >> to allow the generic_copy_file_range() callers to be left unmodified and
> > > > > >> allow the filesystems to default to this implementation.
> > > > > >>
> > > > > >> With this change, I guess that the calls to generic_copy_file_range() from
> > > > > >> the different filesystems can be dropped, as in my initial patch, as they
> > > > > >> will always get -EINVAL.  The other option would be to set the
> > > > > >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> > > > > >> problem we're trying to solve.
> > > > > >
> > > > > > I don't understand the problem.
> > > > > >
> > > > > > What exactly is wrong with the code I suggested?
> > > > > > Why should any filesystem be changed?
> > > > > >
> > > > > > Maybe I am missing something.
> > > > >
> > > > > Ok, I have to do a full brain reboot and start all over.
> > > > >
> > > > > Before that, I picked the code you suggested and tested it.  I've mounted
> > > > > a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> > > > > using /sys/kernel/debug/sched_features as source.  The result was a
> > > > > 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> > > > > early exit in:
> > > > >
> > > > >         if (len == 0)
> > > > >                 return 0;
> > > > >
> > > > > 'len' is set in generic_copy_file_checks().
> > > >
> > > > Good point.. I guess we will need to do all the checks earlier in
> > > > generic_copy_file_checks() including the logic of:
> > > >
> > > >         if (file_in->f_op->remap_file_range &&
> > > >             file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)
> > > >
> > > >
> > > > >
> > > > > This means that we're not solving the original problem anymore (probably
> > > > > since v1 of this patch, haven't checked).
> > > > >
> > > > > Also, re-reading Trond's emails, I read: "... also disallowing the copy
> > > > > from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> > > > > *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> > > > > happening so that tracefs files can't be CFR'ed?
> > > > >
> > > >
> > > > We want to address the report which means calls coming from
> > > > copy_file_range() syscall.
> > > >
> > > > Trond's use case is vfs_copy_file_range() coming from nfsd.
> > > > When he writes about copy from XFS to ext4, he means an
> > > > NFS client is issuing server side copy (on same or different NFS mounts)
> > > > and the NFS server is executing nfsd_copy_file_range() on a source
> > > > file that happens to be on XFS and destination happens to be on ext4.
> > >
> > > NFS also supports a server-to-server copy where the destination server
> > > mounts the source server and reads the data to be copied. Please don't
> > > break that either :)
> >
>
> As long as the copy is via nfsd_copy_file_range() and not from the syscall
> it should not regress.
>
> > This is a case we will eventually need to support for cifs (SMB3) as well.
> >
>
> samba already does server side copy very well without needing any support
> from the kernel.
>
> nfsd also doesn't *need* to use vfs_copy_file_range() it can use kernel APIs
> like the loop in ovl_copy_up_data(). But it does, so we should not regress it.
>
> samba/nfsd can try to use copy_file_range() and it will work if the
> source/target
> fs support it. Otherwise, the server can perfectly well do the copy via other
> available interfaces, just like userspace copy tools.

I was thinking about cifsd ("ksmbd") the kernel server from
Namjae/Sergey etc. which is making excellent progress.

-- 
Thanks,

Steve

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Nicolas Boichat]

On Mon, Feb 15, 2021 at 11:42 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Nicolas Boichat reported an issue when trying to use the copy_file_range
> syscall on a tracefs file.  It failed silently because the file content is
> generated on-the-fly (reporting a size of zero) and copy_file_range needs
> to know in advance how much data is present.

Not sure if you have the whole history, these links and discussion can
help if you want to expand on the commit message:
[1] http://issuetracker.google.com/issues/178332739
[2] https://lkml.org/lkml/2021/1/25/64
[3] https://lkml.org/lkml/2021/1/26/1736
[4] https://patchwork.kernel.org/project/linux-fsdevel/cover/20210212044405.4120619-1-drinkcat@chromium.org/

> This commit restores the cross-fs restrictions that existed prior to
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") and
> removes generic_copy_file_range() calls from ceph, cifs, fuse, and nfs.

It goes beyond that, I think this also prevents copies within the same
FS if copy_file_range is not implemented. Which is IMHO a good thing
since this has been broken on procfs and friends ever since
copy_file_range was implemented (but I assume that nobody ever hit
that before cross-fs became available).

>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Cc: Nicolas Boichat <drinkcat@chromium.org>

You could replace that with Reported-by: Nicolas Boichat <drinkcat@chromium.org>

> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/ceph/file.c     | 21 +++-----------------
>  fs/cifs/cifsfs.c   |  3 ---
>  fs/fuse/file.c     | 21 +++-----------------
>  fs/nfs/nfs4file.c  | 20 +++----------------
>  fs/read_write.c    | 49 ++++++++++------------------------------------
>  include/linux/fs.h |  3 ---
>  6 files changed, 19 insertions(+), 98 deletions(-)
>
[snip]
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..b217cd62ae0d 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1358,40 +1358,12 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
>  }
>  #endif
>
> -/**
> - * generic_copy_file_range - copy data between two files
> - * @file_in:   file structure to read from
> - * @pos_in:    file offset to read from
> - * @file_out:  file structure to write data to
> - * @pos_out:   file offset to write data to
> - * @len:       amount of data to copy
> - * @flags:     copy flags
> - *
> - * This is a generic filesystem helper to copy data from one file to another.
> - * It has no constraints on the source or destination file owners - the files
> - * can belong to different superblocks and different filesystem types. Short
> - * copies are allowed.
> - *
> - * This should be called from the @file_out filesystem, as per the
> - * ->copy_file_range() method.
> - *
> - * Returns the number of bytes copied or a negative error indicating the
> - * failure.
> - */
> -
> -ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> -                               struct file *file_out, loff_t pos_out,
> -                               size_t len, unsigned int flags)
> -{
> -       return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> -                               len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> -}
> -EXPORT_SYMBOL(generic_copy_file_range);
> -
>  static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>                                   struct file *file_out, loff_t pos_out,
>                                   size_t len, unsigned int flags)
>  {
> +       ssize_t ret = -EXDEV;
> +
>         /*
>          * Although we now allow filesystems to handle cross sb copy, passing
>          * a file of the wrong filesystem type to filesystem driver can result
> @@ -1400,14 +1372,14 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>          * several different file_system_type structures, but they all end up
>          * using the same ->copy_file_range() function pointer.
>          */
> -       if (file_out->f_op->copy_file_range &&
> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -               return file_out->f_op->copy_file_range(file_in, pos_in,
> -                                                      file_out, pos_out,
> -                                                      len, flags);
> +       if (!file_out->f_op->copy_file_range)
> +               ret = -EOPNOTSUPP;

This doesn't work as the 0-filesize check is done before that in
vfs_copy_file_range (so the syscall still returns 0, works fine if you
comment out `if (len == 0)`).

Also, you need to check for file_in->f_op->copy_file_range instead,
the problem is if the _input_ filesystem doesn't report sizes or can't
seek properly.

> +       else if (file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> +               ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +                                                     file_out, pos_out,
> +                                                     len, flags);
>
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);
> +       return ret;
>  }
>
>  /*
> @@ -1514,8 +1486,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>         }
>
>         ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                               flags);
> -       WARN_ON_ONCE(ret == -EOPNOTSUPP);
> +                                flags);
>  done:
>         if (ret > 0) {
>                 fsnotify_access(file_in);

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Tue, Feb 16, 2021 at 11:15 PM Steve French <smfrench@gmail.com> wrote:
>
> On Tue, Feb 16, 2021 at 1:40 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Tue, Feb 16, 2021 at 9:31 PM Steve French <smfrench@gmail.com> wrote:
> > >
> > > On Tue, Feb 16, 2021 at 1:29 PM Anna Schumaker
> > > <anna.schumaker@netapp.com> wrote:
> > > >
> > > > On Tue, Feb 16, 2021 at 2:22 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > > >
> > > > > On Tue, Feb 16, 2021 at 8:54 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > > > >
> > > > > > Amir Goldstein <amir73il@gmail.com> writes:
> > > > > >
> > > > > > > On Tue, Feb 16, 2021 at 6:41 PM Luis Henriques <lhenriques@suse.de> wrote:
> > > > > > >>
> > > > > > >> Amir Goldstein <amir73il@gmail.com> writes:
> > > > > > >>
> > > > > > >> >> Ugh.  And I guess overlayfs may have a similar problem.
> > > > > > >> >
> > > > > > >> > Not exactly.
> > > > > > >> > Generally speaking, overlayfs should call vfs_copy_file_range()
> > > > > > >> > with the flags it got from layer above, so if called from nfsd it
> > > > > > >> > will allow cross fs copy and when called from syscall it won't.
> > > > > > >> >
> > > > > > >> > There are some corner cases where overlayfs could benefit from
> > > > > > >> > COPY_FILE_SPLICE (e.g. copy from lower file to upper file), but
> > > > > > >> > let's leave those for now. Just leave overlayfs code as is.
> > > > > > >>
> > > > > > >> Got it, thanks for clarifying.
> > > > > > >>
> > > > > > >> >> > This is easy to solve with a flag COPY_FILE_SPLICE (or something) that
> > > > > > >> >> > is internal to kernel users.
> > > > > > >> >> >
> > > > > > >> >> > FWIW, you may want to look at the loop in ovl_copy_up_data()
> > > > > > >> >> > for improvements to nfsd_copy_file_range().
> > > > > > >> >> >
> > > > > > >> >> > We can move the check out to copy_file_range syscall:
> > > > > > >> >> >
> > > > > > >> >> >         if (flags != 0)
> > > > > > >> >> >                 return -EINVAL;
> > > > > > >> >> >
> > > > > > >> >> > Leave the fallback from all filesystems and check for the
> > > > > > >> >> > COPY_FILE_SPLICE flag inside generic_copy_file_range().
> > > > > > >> >>
> > > > > > >> >> Ok, the diff bellow is just to make sure I understood your suggestion.
> > > > > > >> >>
> > > > > > >> >> The patch will also need to:
> > > > > > >> >>
> > > > > > >> >>  - change nfs and overlayfs calls to vfs_copy_file_range() so that they
> > > > > > >> >>    use the new flag.
> > > > > > >> >>
> > > > > > >> >>  - check flags in generic_copy_file_checks() to make sure only valid flags
> > > > > > >> >>    are used (COPY_FILE_SPLICE at the moment).
> > > > > > >> >>
> > > > > > >> >> Also, where should this flag be defined?  include/uapi/linux/fs.h?
> > > > > > >> >
> > > > > > >> > Grep for REMAP_FILE_
> > > > > > >> > Same header file, same Documentation rst file.
> > > > > > >> >
> > > > > > >> >>
> > > > > > >> >> Cheers,
> > > > > > >> >> --
> > > > > > >> >> Luis
> > > > > > >> >>
> > > > > > >> >> diff --git a/fs/read_write.c b/fs/read_write.c
> > > > > > >> >> index 75f764b43418..341d315d2a96 100644
> > > > > > >> >> --- a/fs/read_write.c
> > > > > > >> >> +++ b/fs/read_write.c
> > > > > > >> >> @@ -1383,6 +1383,13 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > > > > > >> >>                                 struct file *file_out, loff_t pos_out,
> > > > > > >> >>                                 size_t len, unsigned int flags)
> > > > > > >> >>  {
> > > > > > >> >> +       if (!(flags & COPY_FILE_SPLICE)) {
> > > > > > >> >> +               if (!file_out->f_op->copy_file_range)
> > > > > > >> >> +                       return -EOPNOTSUPP;
> > > > > > >> >> +               else if (file_out->f_op->copy_file_range !=
> > > > > > >> >> +                        file_in->f_op->copy_file_range)
> > > > > > >> >> +                       return -EXDEV;
> > > > > > >> >> +       }
> > > > > > >> >
> > > > > > >> > That looks strange, because you are duplicating the logic in
> > > > > > >> > do_copy_file_range(). Maybe better:
> > > > > > >> >
> > > > > > >> > if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> > > > > > >> >         return -EINVAL;
> > > > > > >> > if (flags & COPY_FILE_SPLICE)
> > > > > > >> >        return do_splice_direct(file_in, &pos_in, file_out, &pos_out,
> > > > > > >> >                                  len > MAX_RW_COUNT ? MAX_RW_COUNT : len, 0);
> > > > > > >>
> > > > > > >> My initial reasoning for duplicating the logic in do_copy_file_range() was
> > > > > > >> to allow the generic_copy_file_range() callers to be left unmodified and
> > > > > > >> allow the filesystems to default to this implementation.
> > > > > > >>
> > > > > > >> With this change, I guess that the calls to generic_copy_file_range() from
> > > > > > >> the different filesystems can be dropped, as in my initial patch, as they
> > > > > > >> will always get -EINVAL.  The other option would be to set the
> > > > > > >> COPY_FILE_SPLICE flag in those calls, but that would get us back to the
> > > > > > >> problem we're trying to solve.
> > > > > > >
> > > > > > > I don't understand the problem.
> > > > > > >
> > > > > > > What exactly is wrong with the code I suggested?
> > > > > > > Why should any filesystem be changed?
> > > > > > >
> > > > > > > Maybe I am missing something.
> > > > > >
> > > > > > Ok, I have to do a full brain reboot and start all over.
> > > > > >
> > > > > > Before that, I picked the code you suggested and tested it.  I've mounted
> > > > > > a cephfs filesystem and used xfs_io to execute a 'copy_range' command
> > > > > > using /sys/kernel/debug/sched_features as source.  The result was a
> > > > > > 0-sized file in cephfs.  And the reason is thevfs_copy_file_range()
> > > > > > early exit in:
> > > > > >
> > > > > >         if (len == 0)
> > > > > >                 return 0;
> > > > > >
> > > > > > 'len' is set in generic_copy_file_checks().
> > > > >
> > > > > Good point.. I guess we will need to do all the checks earlier in
> > > > > generic_copy_file_checks() including the logic of:
> > > > >
> > > > >         if (file_in->f_op->remap_file_range &&
> > > > >             file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)
> > > > >
> > > > >
> > > > > >
> > > > > > This means that we're not solving the original problem anymore (probably
> > > > > > since v1 of this patch, haven't checked).
> > > > > >
> > > > > > Also, re-reading Trond's emails, I read: "... also disallowing the copy
> > > > > > from, say, an XFS formatted partition to an ext4 partition".  Isn't that
> > > > > > *exactly* what we're trying to do here?  I.e. _prevent_ these copies from
> > > > > > happening so that tracefs files can't be CFR'ed?
> > > > > >
> > > > >
> > > > > We want to address the report which means calls coming from
> > > > > copy_file_range() syscall.
> > > > >
> > > > > Trond's use case is vfs_copy_file_range() coming from nfsd.
> > > > > When he writes about copy from XFS to ext4, he means an
> > > > > NFS client is issuing server side copy (on same or different NFS mounts)
> > > > > and the NFS server is executing nfsd_copy_file_range() on a source
> > > > > file that happens to be on XFS and destination happens to be on ext4.
> > > >
> > > > NFS also supports a server-to-server copy where the destination server
> > > > mounts the source server and reads the data to be copied. Please don't
> > > > break that either :)
> > >
> >
> > As long as the copy is via nfsd_copy_file_range() and not from the syscall
> > it should not regress.
> >
> > > This is a case we will eventually need to support for cifs (SMB3) as well.
> > >
> >
> > samba already does server side copy very well without needing any support
> > from the kernel.
> >
> > nfsd also doesn't *need* to use vfs_copy_file_range() it can use kernel APIs
> > like the loop in ovl_copy_up_data(). But it does, so we should not regress it.
> >
> > samba/nfsd can try to use copy_file_range() and it will work if the
> > source/target
> > fs support it. Otherwise, the server can perfectly well do the copy via other
> > available interfaces, just like userspace copy tools.
>
> I was thinking about cifsd ("ksmbd") the kernel server from
> Namjae/Sergey etc. which is making excellent progress.
>

You are missing my point.
Never mind which server. The server does not *need* to rely on
vfs_copy_file_range() to copy files from XFS to ext4.
The server is very capable of implementing the fallback generic copy
in case source/target fs do not support native {copy,remap}_file_range().

w.r.t semantics of copy_file_range() syscall vs. the fallback to userespace
'cp' tool (check source file size before copy or not), please note that the
semantics of CIFS_IOC_COPYCHUNK_FILE are that of the former:

        rc = cifs_file_copychunk_range(xid, src_file.file, 0, dst_file, 0,
                                        src_inode->i_size, 0);

It will copy zero bytes if advertised source file size if zero.

NFS server side copy semantics are currently de-facto the same
because both the client and the server will have to pass through this
line in vfs_copy_file_range():

        if (len == 0)
                return 0;

IMO, and this opinion was voiced by several other filesystem developers,
the shortend copy semantics are the correct semantics for copy_file_range()
syscall as well as for vfs_copy_file_range() for internal kernel users.

I guess what this means is that if the 'cp' tool ever tries an opportunistic
copy_file_range() syscall (e.g. --cfr=auto), it may result in zero size copy.

Thanks,
Amir.

[PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystems copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
by filesystems calling directly into the vfs copy_file_range to override
these restrictions.  Right now, only NFS needs to set this flag.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
Ok, I've tried to address all the issues and comments.  Hopefully this v3
is a bit closer to the final fix.

Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/nfsd/vfs.c      |  3 ++-
 fs/read_write.c    | 44 +++++++++++++++++++++++++++++++++++++++++---
 include/linux/fs.h |  7 +++++++
 3 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..14e55822c223 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -578,7 +578,8 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count,
+				   COPY_FILE_SPLICE);
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..40a16003fb05 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1410,6 +1410,33 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
 				       flags);
 }
 
+/*
+ * This helper function checks whether copy_file_range can actually be used,
+ * depending on the source and destination filesystems being the same.
+ *
+ * In-kernel callers may set COPY_FILE_SPLICE to override these checks.
+ */
+static int fops_copy_file_checks(struct file *file_in, struct file *file_out,
+				 unsigned int flags)
+{
+	if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
+		return -EINVAL;
+
+	if (flags & COPY_FILE_SPLICE)
+		return 0;
+	/*
+	 * We got here from userspace, so forbid copies if copy_file_range isn't
+	 * implemented or if we're doing a cross-fs copy.
+	 */
+	if (!file_out->f_op->copy_file_range)
+		return -EOPNOTSUPP;
+	else if (file_out->f_op->copy_file_range !=
+		 file_in->f_op->copy_file_range)
+		return -EXDEV;
+
+	return 0;
+}
+
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1454,14 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/* Only check f_ops if we're not trying to clone */
+	if (!file_in->f_op->remap_file_range ||
+	    (file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)) {
+		ret = fops_copy_file_checks(file_in, file_out, flags);
+		if (ret)
+			return ret;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1474,9 +1509,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 {
 	ssize_t ret;
 
-	if (flags != 0)
-		return -EINVAL;
-
 	ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
 				       flags);
 	if (unlikely(ret))
@@ -1511,6 +1543,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 			ret = cloned;
 			goto done;
 		}
+		ret = fops_copy_file_checks(file_in, file_out, flags);
+		if (ret)
+			return ret;
 	}
 
 	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
@@ -1543,6 +1578,9 @@ SYSCALL_DEFINE6(copy_file_range, int, fd_in, loff_t __user *, off_in,
 	struct fd f_out;
 	ssize_t ret = -EBADF;
 
+	if (flags != 0)
+		return -EINVAL;
+
 	f_in = fdget(fd_in);
 	if (!f_in.file)
 		goto out2;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index fd47deea7c17..6f604926d955 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1815,6 +1815,13 @@ struct dir_context {
  */
 #define REMAP_FILE_ADVISORY		(REMAP_FILE_CAN_SHORTEN)
 
+/*
+ * This flag control the behavior of copy_file_range from internal (kernel)
+ * users.  It can be used to override the policy of forbidding copies when
+ * source and destination filesystems are different.
+ */
+#define COPY_FILE_SPLICE		(1 << 0)
+
 struct iov_iter;
 
 struct file_operations {

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Wed, Feb 17, 2021 at 7:25 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystems copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> by filesystems calling directly into the vfs copy_file_range to override
> these restrictions.  Right now, only NFS needs to set this flag.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Ok, I've tried to address all the issues and comments.  Hopefully this v3
> is a bit closer to the final fix.
>
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c      |  3 ++-
>  fs/read_write.c    | 44 +++++++++++++++++++++++++++++++++++++++++---
>  include/linux/fs.h |  7 +++++++
>  3 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..14e55822c223 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -578,7 +578,8 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count,
> +                                  COPY_FILE_SPLICE);
>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..40a16003fb05 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1410,6 +1410,33 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>                                        flags);
>  }
>
> +/*
> + * This helper function checks whether copy_file_range can actually be used,
> + * depending on the source and destination filesystems being the same.
> + *
> + * In-kernel callers may set COPY_FILE_SPLICE to override these checks.
> + */
> +static int fops_copy_file_checks(struct file *file_in, struct file *file_out,
> +                                unsigned int flags)
> +{
> +       if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> +               return -EINVAL;
> +
> +       if (flags & COPY_FILE_SPLICE)
> +               return 0;
> +       /*
> +        * We got here from userspace, so forbid copies if copy_file_range isn't
> +        * implemented or if we're doing a cross-fs copy.
> +        */

Suggest:

       if (!file_in->f_op->copy_file_range) {
               if (file_in->f_op->copy_file_range !=
                   file_out->f_op->copy_file_range)
                   return -EXDEV;
       } else if (file_in->f_op->remap_file_range) {
               if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
                    return -EXDEV;
       } else {
                return -EOPNOTSUPP;
       }

       return 0;
}

> +
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1454,14 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /* Only check f_ops if we're not trying to clone */
> +       if (!file_in->f_op->remap_file_range ||
> +           (file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)) {
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;
> +       }
> +

and then you don't need this special casing of clone here.

>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1474,9 +1509,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  {
>         ssize_t ret;
>
> -       if (flags != 0)
> -               return -EINVAL;
> -
>         ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
>                                        flags);
>         if (unlikely(ret))
> @@ -1511,6 +1543,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                         ret = cloned;
>                         goto done;
>                 }
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;

and you don't need this here (right?)

and you can remove the checks for same i_sb and same copy_file_range
op that were already tested from vfs_copy_file_range().

Hope I am not missing anything.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Andreas Dilger]

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

On Feb 17, 2021, at 1:08 AM, Amir Goldstein <amir73il@gmail.com> wrote:
> 
> You are missing my point.
> Never mind which server. The server does not *need* to rely on
> vfs_copy_file_range() to copy files from XFS to ext4.
> The server is very capable of implementing the fallback generic copy
> in case source/target fs do not support native {copy,remap}_file_range().
> 
> w.r.t semantics of copy_file_range() syscall vs. the fallback to userespace
> 'cp' tool (check source file size before copy or not), please note that the
> semantics of CIFS_IOC_COPYCHUNK_FILE are that of the former:
> 
>        rc = cifs_file_copychunk_range(xid, src_file.file, 0, dst_file, 0,
>                                        src_inode->i_size, 0);
> 
> It will copy zero bytes if advertised source file size if zero.
> 
> NFS server side copy semantics are currently de-facto the same
> because both the client and the server will have to pass through this
> line in vfs_copy_file_range():
> 
>        if (len == 0)
>                return 0;
> 
> IMO, and this opinion was voiced by several other filesystem developers,
> the shortend copy semantics are the correct semantics for copy_file_range()
> syscall as well as for vfs_copy_file_range() for internal kernel users.
> 
> I guess what this means is that if the 'cp' tool ever tries an opportunistic
> copy_file_range() syscall (e.g. --cfr=auto), it may result in zero size copy.

Having a syscall that does the "wrong thing" when called on two files
doesn't make sense.  Expecting userspace to check whether source/target
files supports CFR is also not practical.  This is trivial for the
kernel to determine and return -EOPNOTSUPP to the caller if the source
file (procfs/sysfs/etc) does not work with CFR properly.

Applications must already handle -EOPNOTSUPP with a fallback, but
expecting all applications that may call copy_file_range() to be
properly coded to handle corner cases is just asking for trouble.
That is doubly true given that an existing widely-used tool like
cp and mv are using this syscall if it is available in the kernel.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Nicolas Boichat]

On Thu, Feb 18, 2021 at 1:25 AM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystems copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").

Note that you also fix intra-filesystem copy_file_range on these
generated filesystems. This is IMHO great, but needs to be mentioned
in the commit message.

>  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> by filesystems calling directly into the vfs copy_file_range to override
> these restrictions.  Right now, only NFS needs to set this flag.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")

So technically this fixes something much older, presumably ever since
copy_file_range was introduced.

> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>

Tested-by: Nicolas Boichat <drinkcat@chromium.org>
but I guess you should not add to the next revision, I'll keep testing
further revisions ,-)

> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Ok, I've tried to address all the issues and comments.  Hopefully this v3
> is a bit closer to the final fix.
>
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c      |  3 ++-
>  fs/read_write.c    | 44 +++++++++++++++++++++++++++++++++++++++++---
>  include/linux/fs.h |  7 +++++++
>  3 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..14e55822c223 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -578,7 +578,8 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count,
> +                                  COPY_FILE_SPLICE);
>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..40a16003fb05 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1410,6 +1410,33 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>                                        flags);
>  }
>
> +/*
> + * This helper function checks whether copy_file_range can actually be used,
> + * depending on the source and destination filesystems being the same.
> + *
> + * In-kernel callers may set COPY_FILE_SPLICE to override these checks.
> + */
> +static int fops_copy_file_checks(struct file *file_in, struct file *file_out,

fops_copy_file_range_checks ?

> +                                unsigned int flags)
> +{
> +       if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> +               return -EINVAL;
> +
> +       if (flags & COPY_FILE_SPLICE)
> +               return 0;
> +       /*
> +        * We got here from userspace, so forbid copies if copy_file_range isn't
> +        * implemented or if we're doing a cross-fs copy.
> +        */
> +       if (!file_out->f_op->copy_file_range)
> +               return -EOPNOTSUPP;

After this is merged, should this be added as an error code to the man page?

> +       else if (file_out->f_op->copy_file_range !=
> +                file_in->f_op->copy_file_range)

Just note, this could be a cross-fs copy (just not a cross-fs_type copy).

> +               return -EXDEV;
> +
> +       return 0;
> +}
> +
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1454,14 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /* Only check f_ops if we're not trying to clone */
> +       if (!file_in->f_op->remap_file_range ||
> +           (file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)) {
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;
> +       }
> +
>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1474,9 +1509,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  {
>         ssize_t ret;
>
> -       if (flags != 0)
> -               return -EINVAL;
> -
>         ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
>                                        flags);
>         if (unlikely(ret))
> @@ -1511,6 +1543,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                         ret = cloned;
>                         goto done;
>                 }
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;
>         }
>
>         ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> @@ -1543,6 +1578,9 @@ SYSCALL_DEFINE6(copy_file_range, int, fd_in, loff_t __user *, off_in,
>         struct fd f_out;
>         ssize_t ret = -EBADF;
>
> +       if (flags != 0)
> +               return -EINVAL;
> +
>         f_in = fdget(fd_in);
>         if (!f_in.file)
>                 goto out2;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index fd47deea7c17..6f604926d955 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1815,6 +1815,13 @@ struct dir_context {
>   */
>  #define REMAP_FILE_ADVISORY            (REMAP_FILE_CAN_SHORTEN)
>
> +/*
> + * This flag control the behavior of copy_file_range from internal (kernel)
> + * users.  It can be used to override the policy of forbidding copies when
> + * source and destination filesystems are different.
> + */
> +#define COPY_FILE_SPLICE               (1 << 0)

nit: BIT(0) ?


> +
>  struct iov_iter;
>
>  struct file_operations {

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Olga Kornievskaia]

On Wed, Feb 17, 2021 at 3:30 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystems copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> by filesystems calling directly into the vfs copy_file_range to override
> these restrictions.  Right now, only NFS needs to set this flag.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Ok, I've tried to address all the issues and comments.  Hopefully this v3
> is a bit closer to the final fix.
>
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description

In my testing, this patch breaks NFS server-to-server copy file.

>
>  fs/nfsd/vfs.c      |  3 ++-
>  fs/read_write.c    | 44 +++++++++++++++++++++++++++++++++++++++++---
>  include/linux/fs.h |  7 +++++++
>  3 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..14e55822c223 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -578,7 +578,8 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count,
> +                                  COPY_FILE_SPLICE);
>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..40a16003fb05 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1410,6 +1410,33 @@ static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>                                        flags);
>  }
>
> +/*
> + * This helper function checks whether copy_file_range can actually be used,
> + * depending on the source and destination filesystems being the same.
> + *
> + * In-kernel callers may set COPY_FILE_SPLICE to override these checks.
> + */
> +static int fops_copy_file_checks(struct file *file_in, struct file *file_out,
> +                                unsigned int flags)
> +{
> +       if (WARN_ON_ONCE(flags & ~COPY_FILE_SPLICE))
> +               return -EINVAL;
> +
> +       if (flags & COPY_FILE_SPLICE)
> +               return 0;
> +       /*
> +        * We got here from userspace, so forbid copies if copy_file_range isn't
> +        * implemented or if we're doing a cross-fs copy.
> +        */
> +       if (!file_out->f_op->copy_file_range)
> +               return -EOPNOTSUPP;
> +       else if (file_out->f_op->copy_file_range !=
> +                file_in->f_op->copy_file_range)
> +               return -EXDEV;
> +
> +       return 0;
> +}
> +
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1454,14 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /* Only check f_ops if we're not trying to clone */
> +       if (!file_in->f_op->remap_file_range ||
> +           (file_inode(file_in)->i_sb == file_inode(file_out)->i_sb)) {
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;
> +       }
> +
>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1474,9 +1509,6 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>  {
>         ssize_t ret;
>
> -       if (flags != 0)
> -               return -EINVAL;
> -
>         ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, &len,
>                                        flags);
>         if (unlikely(ret))
> @@ -1511,6 +1543,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                         ret = cloned;
>                         goto done;
>                 }
> +               ret = fops_copy_file_checks(file_in, file_out, flags);
> +               if (ret)
> +                       return ret;
>         }
>
>         ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> @@ -1543,6 +1578,9 @@ SYSCALL_DEFINE6(copy_file_range, int, fd_in, loff_t __user *, off_in,
>         struct fd f_out;
>         ssize_t ret = -EBADF;
>
> +       if (flags != 0)
> +               return -EINVAL;
> +
>         f_in = fdget(fd_in);
>         if (!f_in.file)
>                 goto out2;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index fd47deea7c17..6f604926d955 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1815,6 +1815,13 @@ struct dir_context {
>   */
>  #define REMAP_FILE_ADVISORY            (REMAP_FILE_CAN_SHORTEN)
>
> +/*
> + * This flag control the behavior of copy_file_range from internal (kernel)
> + * users.  It can be used to override the policy of forbidding copies when
> + * source and destination filesystems are different.
> + */
> +#define COPY_FILE_SPLICE               (1 << 0)
> +
>  struct iov_iter;
>
>  struct file_operations {

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Thu, Feb 18, 2021 at 7:33 AM Olga Kornievskaia <aglo@umich.edu> wrote:
>
> On Wed, Feb 17, 2021 at 3:30 PM Luis Henriques <lhenriques@suse.de> wrote:
> >
> > A regression has been reported by Nicolas Boichat, found while using the
> > copy_file_range syscall to copy a tracefs file.  Before commit
> > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > kernel would return -EXDEV to userspace when trying to copy a file across
> > different filesystems.  After this commit, the syscall doesn't fail anymore
> > and instead returns zero (zero bytes copied), as this file's content is
> > generated on-the-fly and thus reports a size of zero.
> >
> > This patch restores some cross-filesystems copy restrictions that existed
> > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> > by filesystems calling directly into the vfs copy_file_range to override
> > these restrictions.  Right now, only NFS needs to set this flag.
> >
> > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> > Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > ---
> > Ok, I've tried to address all the issues and comments.  Hopefully this v3
> > is a bit closer to the final fix.
> >
> > Changes since v2
> > - do all the required checks earlier, in generic_copy_file_checks(),
> >   adding new checks for ->remap_file_range
> > - new COPY_FILE_SPLICE flag
> > - don't remove filesystem's fallback to generic_copy_file_range()
> > - updated commit changelog (and subject)
> > Changes since v1 (after Amir review)
> > - restored do_copy_file_range() helper
> > - return -EOPNOTSUPP if fs doesn't implement CFR
> > - updated commit description
>
> In my testing, this patch breaks NFS server-to-server copy file.

Hi Olga,

Can you please provide more details on the failed tests.

Does it fail on the client between two nfs mounts or does it fail
on the server? If the latter, between which two filesystems on the server?

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[gregkh]

On Wed, Feb 17, 2021 at 05:50:35PM -0700, Andreas Dilger wrote:
> On Feb 17, 2021, at 1:08 AM, Amir Goldstein <amir73il@gmail.com> wrote:
> > 
> > You are missing my point.
> > Never mind which server. The server does not *need* to rely on
> > vfs_copy_file_range() to copy files from XFS to ext4.
> > The server is very capable of implementing the fallback generic copy
> > in case source/target fs do not support native {copy,remap}_file_range().
> > 
> > w.r.t semantics of copy_file_range() syscall vs. the fallback to userespace
> > 'cp' tool (check source file size before copy or not), please note that the
> > semantics of CIFS_IOC_COPYCHUNK_FILE are that of the former:
> > 
> >        rc = cifs_file_copychunk_range(xid, src_file.file, 0, dst_file, 0,
> >                                        src_inode->i_size, 0);
> > 
> > It will copy zero bytes if advertised source file size if zero.
> > 
> > NFS server side copy semantics are currently de-facto the same
> > because both the client and the server will have to pass through this
> > line in vfs_copy_file_range():
> > 
> >        if (len == 0)
> >                return 0;
> > 
> > IMO, and this opinion was voiced by several other filesystem developers,
> > the shortend copy semantics are the correct semantics for copy_file_range()
> > syscall as well as for vfs_copy_file_range() for internal kernel users.
> > 
> > I guess what this means is that if the 'cp' tool ever tries an opportunistic
> > copy_file_range() syscall (e.g. --cfr=auto), it may result in zero size copy.
> 
> Having a syscall that does the "wrong thing" when called on two files
> doesn't make sense.  Expecting userspace to check whether source/target
> files supports CFR is also not practical.  This is trivial for the
> kernel to determine and return -EOPNOTSUPP to the caller if the source
> file (procfs/sysfs/etc) does not work with CFR properly.

How does the kernel "know" that a specific file in a specific filesystem
will not work with CFR "properly"?  That goes back to the original patch
which tried to label each and every filesystem type with a
"supported/not supported" type of flag, which was going to be a mess,
especially as it seems that this might be a file-specific thing, not a
filesystem-specific thing.

The goal of the patch _should_ be that the kernel figure it out itself,
but so far no one seems to be able to explain how that can be done :(

So, any hints?

thanks,

greg k-h

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

This whole idea of cross-device copie has always been a horrible idea,
and I've been arguing against it since the patches were posted.

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Christoph Hellwig]

On Wed, Feb 17, 2021 at 05:26:54PM +0000, Luis Henriques wrote:
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
> 
> This patch restores some cross-filesystems copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> by filesystems calling directly into the vfs copy_file_range to override
> these restrictions.  Right now, only NFS needs to set this flag.

No need for the flag.  Jyst fall back to splicing in the only caller
that wants it.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> Looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> This whole idea of cross-device copie has always been a horrible idea,
> and I've been arguing against it since the patches were posted.

Ok. I'm good with this v2 as well, but need to add the fallback to
do_splice_direct()
in nfsd_copy_file_range(), because this patch breaks it.

And the commit message of v3 is better in describing the reported issue.

Thanks,
Amir.

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> Looks good:
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>> This whole idea of cross-device copie has always been a horrible idea,
>> and I've been arguing against it since the patches were posted.
>
> Ok. I'm good with this v2 as well, but need to add the fallback to
> do_splice_direct()
> in nfsd_copy_file_range(), because this patch breaks it.
>
> And the commit message of v3 is better in describing the reported issue.

Except that, as I said in a previous email, v2 doesn't really fix the
issue: all the checks need to be done earlier in generic_copy_file_checks().

I'll work on getting v4, based on v2 and but moving the checks and
implementing your review suggestions to v3 (plus this nfs change).

Cheers,
-- 
Luis

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Luis Henriques]

Luis Henriques <lhenriques@suse.de> writes:

> Amir Goldstein <amir73il@gmail.com> writes:
>
>> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig <hch@infradead.org> wrote:
>>>
>>> Looks good:
>>>
>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>
>>> This whole idea of cross-device copie has always been a horrible idea,
>>> and I've been arguing against it since the patches were posted.
>>
>> Ok. I'm good with this v2 as well, but need to add the fallback to
>> do_splice_direct()
>> in nfsd_copy_file_range(), because this patch breaks it.
>>
>> And the commit message of v3 is better in describing the reported issue.
>
> Except that, as I said in a previous email, v2 doesn't really fix the
> issue: all the checks need to be done earlier in generic_copy_file_checks().
>
> I'll work on getting v4, based on v2 and but moving the checks and
> implementing your review suggestions to v3 (plus this nfs change).

There's something else:

The filesystems (nfs, ceph, cifs, fuse) rely on the fallback to
generic_copy_file_range() if something's wrong.  And this "something's
wrong" is fs specific.  For example: in ceph it is possible to offload the
file copy to the OSDs even if the files are in different filesystems as
long as these filesystems are on the *same* ceph cluster.  If the copy
being done is across two different clusters, then the copy reverts to
splice.  This means that the boilerplate code being removed in v2 of this
patch needs to be restored and replace by:

	ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
				     len, flags);

	if (ret == -EOPNOTSUPP || ret == -EXDEV)
		ret = do_splice_direct(src_file, &src_off, dst_file, &dst_off,
				       len > MAX_RW_COUNT ? MAX_RW_COUNT : len,
				       flags);
	return ret;

A quick look at the other filesystems code indicate similar patterns.
Since at this point we've gone through all the syscall checks already,
calling do_splice_direct() shouldn't be a huge change.  But I may be
missing something.  Again.  Which is quite likely :-)

Cheers,
-- 
Luis

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Amir Goldstein]

On Thu, Feb 18, 2021 at 2:14 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> Luis Henriques <lhenriques@suse.de> writes:
>
> > Amir Goldstein <amir73il@gmail.com> writes:
> >
> >> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig <hch@infradead.org> wrote:
> >>>
> >>> Looks good:
> >>>
> >>> Reviewed-by: Christoph Hellwig <hch@lst.de>
> >>>
> >>> This whole idea of cross-device copie has always been a horrible idea,
> >>> and I've been arguing against it since the patches were posted.
> >>
> >> Ok. I'm good with this v2 as well, but need to add the fallback to
> >> do_splice_direct()
> >> in nfsd_copy_file_range(), because this patch breaks it.
> >>
> >> And the commit message of v3 is better in describing the reported issue.
> >
> > Except that, as I said in a previous email, v2 doesn't really fix the
> > issue: all the checks need to be done earlier in generic_copy_file_checks().
> >
> > I'll work on getting v4, based on v2 and but moving the checks and
> > implementing your review suggestions to v3 (plus this nfs change).
>
> There's something else:
>
> The filesystems (nfs, ceph, cifs, fuse) rely on the fallback to
> generic_copy_file_range() if something's wrong.  And this "something's
> wrong" is fs specific.  For example: in ceph it is possible to offload the
> file copy to the OSDs even if the files are in different filesystems as
> long as these filesystems are on the *same* ceph cluster.  If the copy
> being done is across two different clusters, then the copy reverts to
> splice.  This means that the boilerplate code being removed in v2 of this
> patch needs to be restored and replace by:
>
>         ret = __ceph_copy_file_range(src_file, src_off, dst_file, dst_off,
>                                      len, flags);
>
>         if (ret == -EOPNOTSUPP || ret == -EXDEV)
>                 ret = do_splice_direct(src_file, &src_off, dst_file, &dst_off,
>                                        len > MAX_RW_COUNT ? MAX_RW_COUNT : len,
>                                        flags);
>         return ret;
>

Why not leave the filesystem code as is and leave the
generic_copy_file_range() helper? Less churn.

Then nfsd_copy_file_range() can also fallback to generic_copy_file_range().

Thanks,
Amir.

[PATCH v4] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to use generic_copy_file_range() instead of
vfs_copy_file_range() so that it can still fall-back to splice without going
through all the checks.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
And here's v4.  I'd like to request help for testing.  I know Nicolas is
doing that (thanks!  and thanks for the reviews).  But it would be great to
get at least the nfs code tested.  Olga, can you help here?

Changes since v3
- dropped the COPY_FILE_SPLICE flag
- kept the f_op's checks early in generic_copy_file_checks, implementing
  Amir's suggestions
- modified nfsd to use generic_copy_file_range()
Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/nfsd/vfs.c   |  2 +-
 fs/read_write.c | 50 +++++++++++++++++++++++--------------------------
 2 files changed, 24 insertions(+), 28 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..49dd28ee2602 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -578,7 +578,7 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	return generic_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..214d44f7cbfa 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 }
 EXPORT_SYMBOL(generic_copy_file_range);
 
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/*
+	 * Although we now allow filesystems to handle cross sb copy, passing
+	 * a file of the wrong filesystem type to filesystem driver can result
+	 * in an attempt to dereference the wrong type of ->private_data, so
+	 * avoid doing that until we really have a good reason.  NFS defines
+	 * several different file_system_type structures, but they all end up
+	 * using the same ->copy_file_range() function pointer.
+	 */
+	if (file_out->f_op->copy_file_range) {
+		if (file_in->f_op->copy_file_range !=
+		    file_out->f_op->copy_file_range)
+			return -EXDEV;
+	} else if (file_in->f_op->remap_file_range) {
+		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+			return -EXDEV;
+	} else {
+                return -EOPNOTSUPP;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 	 * Try cloning first, this is supported by more file systems, and
 	 * more efficient if both clone and copy are supported (e.g. NFS).
 	 */
-	if (file_in->f_op->remap_file_range &&
-	    file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
+	if (file_in->f_op->remap_file_range) {
 		loff_t cloned;
 
 		cloned = file_in->f_op->remap_file_range(file_in, pos_in,
@@ -1513,9 +1509,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 		}
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+	ret = file_out->f_op->copy_file_range(file_in, pos_in,
+					      file_out, pos_out,
+					      len, flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);

Re: [PATCH v4] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Thu, Feb 18, 2021 at 4:35 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to use generic_copy_file_range() instead of
> vfs_copy_file_range() so that it can still fall-back to splice without going
> through all the checks.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> And here's v4.  I'd like to request help for testing.  I know Nicolas is
> doing that (thanks!  and thanks for the reviews).  But it would be great to
> get at least the nfs code tested.  Olga, can you help here?
>
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks, implementing
>   Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c   |  2 +-
>  fs/read_write.c | 50 +++++++++++++++++++++++--------------------------
>  2 files changed, 24 insertions(+), 28 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..49dd28ee2602 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -578,7 +578,7 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       return generic_copy_file_range(src, src_pos, dst, dst_pos, count, 0);

That is not the desired change.
It should try vfs_copy_file_range() and fallback to generic_copy_file_range()
for EXDEV and EOPNOTSUPP.
I will explain why.
This code runs on nfs server.
The nfs client requested remote server side copy offload using
nfs4_copy_file_range() and remote request is handled here.
It is not enough to generic_copy_file_range() on the server because
the source and destination themselves can be on yet another remote
location (cifs/ceph/nfs), so this is why calling vfs_copy_file_range()
here is important.
At least that is my understanding.
Unlike userspace copy fallback, if the server returns -EXDEV the client
will need to transfer the data over the network.
That is why the generic_copy_file_range() fallback is important.


>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..214d44f7cbfa 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>  }
>  EXPORT_SYMBOL(generic_copy_file_range);
>
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                 struct file *file_out, loff_t pos_out,
> -                                 size_t len, unsigned int flags)
> -{
> -       /*
> -        * Although we now allow filesystems to handle cross sb copy, passing
> -        * a file of the wrong filesystem type to filesystem driver can result
> -        * in an attempt to dereference the wrong type of ->private_data, so
> -        * avoid doing that until we really have a good reason.  NFS defines
> -        * several different file_system_type structures, but they all end up
> -        * using the same ->copy_file_range() function pointer.
> -        */
> -       if (file_out->f_op->copy_file_range &&
> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -               return file_out->f_op->copy_file_range(file_in, pos_in,
> -                                                      file_out, pos_out,
> -                                                      len, flags);
> -
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);
> -}
> -
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /*
> +        * Although we now allow filesystems to handle cross sb copy, passing
> +        * a file of the wrong filesystem type to filesystem driver can result
> +        * in an attempt to dereference the wrong type of ->private_data, so
> +        * avoid doing that until we really have a good reason.  NFS defines
> +        * several different file_system_type structures, but they all end up
> +        * using the same ->copy_file_range() function pointer.
> +        */
> +       if (file_out->f_op->copy_file_range) {
> +               if (file_in->f_op->copy_file_range !=
> +                   file_out->f_op->copy_file_range)
> +                       return -EXDEV;
> +       } else if (file_in->f_op->remap_file_range) {
> +               if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +                       return -EXDEV;
> +       } else {
> +                return -EOPNOTSUPP;
> +       }
> +
>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>          * Try cloning first, this is supported by more file systems, and
>          * more efficient if both clone and copy are supported (e.g. NFS).
>          */
> -       if (file_in->f_op->remap_file_range &&
> -           file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
> +       if (file_in->f_op->remap_file_range) {
>                 loff_t cloned;
>
>                 cloned = file_in->f_op->remap_file_range(file_in, pos_in,
> @@ -1513,9 +1509,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                 }
>         }
>
> -       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                               flags);
> -       WARN_ON_ONCE(ret == -EOPNOTSUPP);
> +       ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +                                             file_out, pos_out,
> +                                             len, flags);

I see you have made an assumption here that if we did not clone then
file_out->f_op->copy_file_range must be valid.
It is not true.
file_out->f_op->copy_file_range could be NULL and we got here becauses
remap_file_range was attempted and failed.
So you still need to check for non-NULL file_out->f_op->copy_file_range
here just like it was before the regressing commit.

Otherwise, looks ok to me, but without NFS testing we won't know for sure
It's a tricky one...

Thanks,
Amir.

[PATCH v5] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to fall-back into generic_copy_file_range() in case
vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
And v5!  Sorry.  Sure, it makes sense to go through the all the vfs_cfr()
checks first.

Again, here's my request for testing.

Changes since v4
- nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
  or -EXDEV.
Changes since v3
- dropped the COPY_FILE_SPLICE flag
- kept the f_op's checks early in generic_copy_file_checks, implementing
  Amir's suggestions
- modified nfsd to use generic_copy_file_range()
Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description
 fs/nfsd/vfs.c   |  8 +++++++-
 fs/read_write.c | 50 +++++++++++++++++++++++--------------------------
 2 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..23dab0fa9087 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
 ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 			     u64 dst_pos, u64 count)
 {
+	ssize_t ret;
 
 	/*
 	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
@@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+
+	if (ret == -EOPNOTSUPP || ret == -EXDEV)
+		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
+					      count, 0);
+	return ret;
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..214d44f7cbfa 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 }
 EXPORT_SYMBOL(generic_copy_file_range);
 
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/*
+	 * Although we now allow filesystems to handle cross sb copy, passing
+	 * a file of the wrong filesystem type to filesystem driver can result
+	 * in an attempt to dereference the wrong type of ->private_data, so
+	 * avoid doing that until we really have a good reason.  NFS defines
+	 * several different file_system_type structures, but they all end up
+	 * using the same ->copy_file_range() function pointer.
+	 */
+	if (file_out->f_op->copy_file_range) {
+		if (file_in->f_op->copy_file_range !=
+		    file_out->f_op->copy_file_range)
+			return -EXDEV;
+	} else if (file_in->f_op->remap_file_range) {
+		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+			return -EXDEV;
+	} else {
+                return -EOPNOTSUPP;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 	 * Try cloning first, this is supported by more file systems, and
 	 * more efficient if both clone and copy are supported (e.g. NFS).
 	 */
-	if (file_in->f_op->remap_file_range &&
-	    file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
+	if (file_in->f_op->remap_file_range) {
 		loff_t cloned;
 
 		cloned = file_in->f_op->remap_file_range(file_in, pos_in,
@@ -1513,9 +1509,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 		}
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+	ret = file_out->f_op->copy_file_range(file_in, pos_in,
+					      file_out, pos_out,
+					      len, flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);

Re: [PATCH v5] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Thu, Feb 18, 2021 at 5:16 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> And v5!  Sorry.  Sure, it makes sense to go through the all the vfs_cfr()
> checks first.

You missed my other comment on v4...

not checking NULL copy_file_range case.

Thanks,
Amir.

Re: [PATCH v3] vfs: fix copy_file_range regression in cross-fs copies

[Olga Kornievskaia]

On Thu, Feb 18, 2021 at 1:48 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Feb 18, 2021 at 7:33 AM Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > On Wed, Feb 17, 2021 at 3:30 PM Luis Henriques <lhenriques@suse.de> wrote:
> > >
> > > A regression has been reported by Nicolas Boichat, found while using the
> > > copy_file_range syscall to copy a tracefs file.  Before commit
> > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > > kernel would return -EXDEV to userspace when trying to copy a file across
> > > different filesystems.  After this commit, the syscall doesn't fail anymore
> > > and instead returns zero (zero bytes copied), as this file's content is
> > > generated on-the-fly and thus reports a size of zero.
> > >
> > > This patch restores some cross-filesystems copy restrictions that existed
> > > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > devices").  It also introduces a flag (COPY_FILE_SPLICE) that can be used
> > > by filesystems calling directly into the vfs copy_file_range to override
> > > these restrictions.  Right now, only NFS needs to set this flag.
> > >
> > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > > Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > > Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> > > Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> > > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > > ---
> > > Ok, I've tried to address all the issues and comments.  Hopefully this v3
> > > is a bit closer to the final fix.
> > >
> > > Changes since v2
> > > - do all the required checks earlier, in generic_copy_file_checks(),
> > >   adding new checks for ->remap_file_range
> > > - new COPY_FILE_SPLICE flag
> > > - don't remove filesystem's fallback to generic_copy_file_range()
> > > - updated commit changelog (and subject)
> > > Changes since v1 (after Amir review)
> > > - restored do_copy_file_range() helper
> > > - return -EOPNOTSUPP if fs doesn't implement CFR
> > > - updated commit description
> >
> > In my testing, this patch breaks NFS server-to-server copy file.
>
> Hi Olga,
>
> Can you please provide more details on the failed tests.
>
> Does it fail on the client between two nfs mounts or does it fail
> on the server? If the latter, between which two filesystems on the server?
>

It was a pilot error. V3 worked. I'm having some other issues with
server to server copy code but they seem to be unrelated to this. I
will test the new v6 versions when it comes out.

> Thanks,
> Amir.

Re: [PATCH v5] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

Amir Goldstein <amir73il@gmail.com> writes:

> On Thu, Feb 18, 2021 at 5:16 PM Luis Henriques <lhenriques@suse.de> wrote:
>>
>> A regression has been reported by Nicolas Boichat, found while using the
>> copy_file_range syscall to copy a tracefs file.  Before commit
>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
>> kernel would return -EXDEV to userspace when trying to copy a file across
>> different filesystems.  After this commit, the syscall doesn't fail anymore
>> and instead returns zero (zero bytes copied), as this file's content is
>> generated on-the-fly and thus reports a size of zero.
>>
>> This patch restores some cross-filesystem copy restrictions that existed
>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> devices").  Filesystems are still allowed to fall-back to the VFS
>> generic_copy_file_range() implementation, but that has now to be done
>> explicitly.
>>
>> nfsd is also modified to fall-back into generic_copy_file_range() in case
>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>>
>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
>> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
>> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
>> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> ---
>> And v5!  Sorry.  Sure, it makes sense to go through the all the vfs_cfr()
>> checks first.
>
> You missed my other comment on v4...
>
> not checking NULL copy_file_range case.

Ah, yeah I did missed it.  I'll follow up with yet another revision.

Cheers,
-- 
Luis

[PATCH v6] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to fall-back into generic_copy_file_range() in case
vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
And v6 is upon us.  Behold!

Changes since v5
- check if ->copy_file_range is NULL before calling it
Changes since v4
- nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
  or -EXDEV.
Changes since v3
- dropped the COPY_FILE_SPLICE flag
- kept the f_op's checks early in generic_copy_file_checks, implementing
  Amir's suggestions
- modified nfsd to use generic_copy_file_range()
Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/nfsd/vfs.c   |  8 +++++++-
 fs/read_write.c | 53 ++++++++++++++++++++++++-------------------------
 2 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..23dab0fa9087 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
 ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 			     u64 dst_pos, u64 count)
 {
+	ssize_t ret;
 
 	/*
 	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
@@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+
+	if (ret == -EOPNOTSUPP || ret == -EXDEV)
+		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
+					      count, 0);
+	return ret;
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..0348aaa9e237 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 }
 EXPORT_SYMBOL(generic_copy_file_range);
 
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/*
+	 * Although we now allow filesystems to handle cross sb copy, passing
+	 * a file of the wrong filesystem type to filesystem driver can result
+	 * in an attempt to dereference the wrong type of ->private_data, so
+	 * avoid doing that until we really have a good reason.  NFS defines
+	 * several different file_system_type structures, but they all end up
+	 * using the same ->copy_file_range() function pointer.
+	 */
+	if (file_out->f_op->copy_file_range) {
+		if (file_in->f_op->copy_file_range !=
+		    file_out->f_op->copy_file_range)
+			return -EXDEV;
+	} else if (file_in->f_op->remap_file_range) {
+		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+			return -EXDEV;
+	} else {
+                return -EOPNOTSUPP;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 	 * Try cloning first, this is supported by more file systems, and
 	 * more efficient if both clone and copy are supported (e.g. NFS).
 	 */
-	if (file_in->f_op->remap_file_range &&
-	    file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
+	if (file_in->f_op->remap_file_range) {
 		loff_t cloned;
 
 		cloned = file_in->f_op->remap_file_range(file_in, pos_in,
@@ -1511,11 +1507,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 			ret = cloned;
 			goto done;
 		}
+		/* Resort to copy_file_range if implemented. */
+		ret = -EOPNOTSUPP;
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+	if (file_out->f_op->copy_file_range)
+		ret = file_out->f_op->copy_file_range(file_in, pos_in,
+						      file_out, pos_out,
+						      len, flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);

Re: [PATCH v2] vfs: prevent copy_file_range to copy across devices

[Steve French]

On Thu, Feb 18, 2021 at 4:03 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Feb 18, 2021 at 9:42 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > Looks good:
> >
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> >
> > This whole idea of cross-device copie has always been a horrible idea,
> > and I've been arguing against it since the patches were posted.
>
> Ok. I'm good with this v2 as well, but need to add the fallback to
> do_splice_direct()
> in nfsd_copy_file_range(), because this patch breaks it.

Interestingly, for ksmbd (cifsd) looks like they already do splice not
copy_file_range


-- 
Thanks,

Steve

Re: [PATCH v6] vfs: fix copy_file_range regression in cross-fs copies

[Olga Kornievskaia]

On Thu, Feb 18, 2021 at 12:33 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> And v6 is upon us.  Behold!


> Changes since v5
> - check if ->copy_file_range is NULL before calling it
> Changes since v4
> - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
>   or -EXDEV.
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks, implementing
>   Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c   |  8 +++++++-
>  fs/read_write.c | 53 ++++++++++++++++++++++++-------------------------
>  2 files changed, 33 insertions(+), 28 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..23dab0fa9087 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
>  ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>                              u64 dst_pos, u64 count)
>  {
> +       ssize_t ret;
>
>         /*
>          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +
> +       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> +               ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> +                                             count, 0);
> +       return ret;
>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..0348aaa9e237 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>  }
>  EXPORT_SYMBOL(generic_copy_file_range);
>
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                 struct file *file_out, loff_t pos_out,
> -                                 size_t len, unsigned int flags)
> -{
> -       /*
> -        * Although we now allow filesystems to handle cross sb copy, passing
> -        * a file of the wrong filesystem type to filesystem driver can result
> -        * in an attempt to dereference the wrong type of ->private_data, so
> -        * avoid doing that until we really have a good reason.  NFS defines
> -        * several different file_system_type structures, but they all end up
> -        * using the same ->copy_file_range() function pointer.
> -        */
> -       if (file_out->f_op->copy_file_range &&
> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -               return file_out->f_op->copy_file_range(file_in, pos_in,
> -                                                      file_out, pos_out,
> -                                                      len, flags);
> -
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);
> -}
> -
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /*
> +        * Although we now allow filesystems to handle cross sb copy, passing
> +        * a file of the wrong filesystem type to filesystem driver can result
> +        * in an attempt to dereference the wrong type of ->private_data, so
> +        * avoid doing that until we really have a good reason.  NFS defines
> +        * several different file_system_type structures, but they all end up
> +        * using the same ->copy_file_range() function pointer.
> +        */
> +       if (file_out->f_op->copy_file_range) {
> +               if (file_in->f_op->copy_file_range !=
> +                   file_out->f_op->copy_file_range)
> +                       return -EXDEV;
> +       } else if (file_in->f_op->remap_file_range) {
> +               if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +                       return -EXDEV;
> +       } else {
> +                return -EOPNOTSUPP;
> +       }
> +
>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>          * Try cloning first, this is supported by more file systems, and
>          * more efficient if both clone and copy are supported (e.g. NFS).
>          */
> -       if (file_in->f_op->remap_file_range &&
> -           file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
> +       if (file_in->f_op->remap_file_range) {
>                 loff_t cloned;

This chunk breaks NFS. You are removing the check that the source and
destination for the CLONE operation are the same superblock and that
leads to the fact that when NFS does a copy between 2 different NFS
servers, it would try CLONE first which is not allowed. NFS relied on
this check to be done by the VFS layer. Either don't remove it or,
otherwise, fix the NFS clone's code to not send the CLONE and error
accordingly so that the COPY is done as it should have been.

>                 cloned = file_in->f_op->remap_file_range(file_in, pos_in,
> @@ -1511,11 +1507,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                         ret = cloned;
>                         goto done;
>                 }
> +               /* Resort to copy_file_range if implemented. */
> +               ret = -EOPNOTSUPP;
>         }
>
> -       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                               flags);
> -       WARN_ON_ONCE(ret == -EOPNOTSUPP);
> +       if (file_out->f_op->copy_file_range)
> +               ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +                                                     file_out, pos_out,
> +                                                     len, flags);
>  done:
>         if (ret > 0) {
>                 fsnotify_access(file_in);

Re: [PATCH v6] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Fri, Feb 19, 2021 at 11:18 PM Olga Kornievskaia <aglo@umich.edu> wrote:
>
> On Thu, Feb 18, 2021 at 12:33 PM Luis Henriques <lhenriques@suse.de> wrote:
> >
> > A regression has been reported by Nicolas Boichat, found while using the
> > copy_file_range syscall to copy a tracefs file.  Before commit
> > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > kernel would return -EXDEV to userspace when trying to copy a file across
> > different filesystems.  After this commit, the syscall doesn't fail anymore
> > and instead returns zero (zero bytes copied), as this file's content is
> > generated on-the-fly and thus reports a size of zero.
> >
> > This patch restores some cross-filesystem copy restrictions that existed
> > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > devices").  Filesystems are still allowed to fall-back to the VFS
> > generic_copy_file_range() implementation, but that has now to be done
> > explicitly.
> >
> > nfsd is also modified to fall-back into generic_copy_file_range() in case
> > vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> >
> > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> > Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> > Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > ---
> > And v6 is upon us.  Behold!
>
>
> > Changes since v5
> > - check if ->copy_file_range is NULL before calling it
> > Changes since v4
> > - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
> >   or -EXDEV.
> > Changes since v3
> > - dropped the COPY_FILE_SPLICE flag
> > - kept the f_op's checks early in generic_copy_file_checks, implementing
> >   Amir's suggestions
> > - modified nfsd to use generic_copy_file_range()
> > Changes since v2
> > - do all the required checks earlier, in generic_copy_file_checks(),
> >   adding new checks for ->remap_file_range
> > - new COPY_FILE_SPLICE flag
> > - don't remove filesystem's fallback to generic_copy_file_range()
> > - updated commit changelog (and subject)
> > Changes since v1 (after Amir review)
> > - restored do_copy_file_range() helper
> > - return -EOPNOTSUPP if fs doesn't implement CFR
> > - updated commit description
> >
> >  fs/nfsd/vfs.c   |  8 +++++++-
> >  fs/read_write.c | 53 ++++++++++++++++++++++++-------------------------
> >  2 files changed, 33 insertions(+), 28 deletions(-)
> >
> > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> > index 04937e51de56..23dab0fa9087 100644
> > --- a/fs/nfsd/vfs.c
> > +++ b/fs/nfsd/vfs.c
> > @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
> >  ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> >                              u64 dst_pos, u64 count)
> >  {
> > +       ssize_t ret;
> >
> >         /*
> >          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> > @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> >          * limit like this and pipeline multiple COPY requests.
> >          */
> >         count = min_t(u64, count, 1 << 22);
> > -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > +       ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > +
> > +       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> > +               ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> > +                                             count, 0);
> > +       return ret;
> >  }
> >
> >  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> > diff --git a/fs/read_write.c b/fs/read_write.c
> > index 75f764b43418..0348aaa9e237 100644
> > --- a/fs/read_write.c
> > +++ b/fs/read_write.c
> > @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> >  }
> >  EXPORT_SYMBOL(generic_copy_file_range);
> >
> > -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> > -                                 struct file *file_out, loff_t pos_out,
> > -                                 size_t len, unsigned int flags)
> > -{
> > -       /*
> > -        * Although we now allow filesystems to handle cross sb copy, passing
> > -        * a file of the wrong filesystem type to filesystem driver can result
> > -        * in an attempt to dereference the wrong type of ->private_data, so
> > -        * avoid doing that until we really have a good reason.  NFS defines
> > -        * several different file_system_type structures, but they all end up
> > -        * using the same ->copy_file_range() function pointer.
> > -        */
> > -       if (file_out->f_op->copy_file_range &&
> > -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> > -               return file_out->f_op->copy_file_range(file_in, pos_in,
> > -                                                      file_out, pos_out,
> > -                                                      len, flags);
> > -
> > -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> > -                                      flags);
> > -}
> > -
> >  /*
> >   * Performs necessary checks before doing a file copy
> >   *
> > @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
> >         loff_t size_in;
> >         int ret;
> >
> > +       /*
> > +        * Although we now allow filesystems to handle cross sb copy, passing
> > +        * a file of the wrong filesystem type to filesystem driver can result
> > +        * in an attempt to dereference the wrong type of ->private_data, so
> > +        * avoid doing that until we really have a good reason.  NFS defines
> > +        * several different file_system_type structures, but they all end up
> > +        * using the same ->copy_file_range() function pointer.
> > +        */
> > +       if (file_out->f_op->copy_file_range) {
> > +               if (file_in->f_op->copy_file_range !=
> > +                   file_out->f_op->copy_file_range)
> > +                       return -EXDEV;
> > +       } else if (file_in->f_op->remap_file_range) {
> > +               if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> > +                       return -EXDEV;
> > +       } else {
> > +                return -EOPNOTSUPP;
> > +       }
> > +
> >         ret = generic_file_rw_checks(file_in, file_out);
> >         if (ret)
> >                 return ret;
> > @@ -1499,8 +1496,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> >          * Try cloning first, this is supported by more file systems, and
> >          * more efficient if both clone and copy are supported (e.g. NFS).
> >          */
> > -       if (file_in->f_op->remap_file_range &&
> > -           file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
> > +       if (file_in->f_op->remap_file_range) {
> >                 loff_t cloned;
>
> This chunk breaks NFS. You are removing the check that the source and
> destination for the CLONE operation are the same superblock and that
> leads to the fact that when NFS does a copy between 2 different NFS
> servers, it would try CLONE first which is not allowed. NFS relied on
> this check to be done by the VFS layer. Either don't remove it or,
> otherwise, fix the NFS clone's code to not send the CLONE and error
> accordingly so that the COPY is done as it should have been.
>

Right, we need to add this check back (not only for NFS).

However, I was looking at the change that introduced this opportunistic
call for clone_file_range() into copy_file_range():

commit a76b5b04375f974579c83433b06466758c0c552c
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Dec 9 16:17:19 2016 -0800

    fs: try to clone files first in vfs_copy_file_range

    A clone is a perfectly fine implementation of a file copy, so most
    file systems just implement the copy that way.  Instead of duplicating
    this logic move it to the VFS.  Currently btrfs and XFS implement copies
    the same way as clones and there is no behavior change for them, cifs
    only implements clones and grow support for copy_file_range with this
    patch.  NFS implements both, so this will allow copy_file_range to work
    on servers that only implement CLONE and be lot more efficient on servers
    that implements CLONE and COPY.

And I was thinking to myself that like the change that brought us here
("vfs: allow copy_file_range to copy across devices"), this change was done
for a certain purpose (serve copy_file_range() by fs that implement CLONE),
but that last part (prefer CLONE over COPY) also sounds like an optimization
that nobody asked for and could lead to unexpected behavior down the road.

I think that if a filesystem implements both methods (COPY and CLONE)
and user called to COPY API, we need to call the more specialized COPY
method and not try the CLONE method, because filesystem should be very
capable of making this optimization internally.

This could have been a hypothetical question, but there are actually
two filesystems that implement both COPY and CLONE, so let's ask the
developers what they think VFS should call.

Olga, Trond, Steve, which methods of your filesystem do you think that
vfs_copy_file_range() should call?
1. Only copy_file_range()?
2. Both copy_file_range() and remap_file_range()?
3. CLONE before COPY or the other way around?

Thanks,
Amir.

[PATCH v7] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to fall-back into generic_copy_file_range() in case
vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
Changes since v6
- restored i_sb checks for the clone operation
Changes since v5
- check if ->copy_file_range is NULL before calling it
Changes since v4
- nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
  or -EXDEV.
Changes since v3
- dropped the COPY_FILE_SPLICE flag
- kept the f_op's checks early in generic_copy_file_checks, implementing
  Amir's suggestions
- modified nfsd to use generic_copy_file_range()
Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/nfsd/vfs.c   |  8 +++++++-
 fs/read_write.c | 50 ++++++++++++++++++++++++-------------------------
 2 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..23dab0fa9087 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
 ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 			     u64 dst_pos, u64 count)
 {
+	ssize_t ret;
 
 	/*
 	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
@@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+
+	if (ret == -EOPNOTSUPP || ret == -EXDEV)
+		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
+					      count, 0);
+	return ret;
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..463345c0ee30 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 }
 EXPORT_SYMBOL(generic_copy_file_range);
 
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/*
+	 * Although we now allow filesystems to handle cross sb copy, passing
+	 * a file of the wrong filesystem type to filesystem driver can result
+	 * in an attempt to dereference the wrong type of ->private_data, so
+	 * avoid doing that until we really have a good reason.  NFS defines
+	 * several different file_system_type structures, but they all end up
+	 * using the same ->copy_file_range() function pointer.
+	 */
+	if (file_out->f_op->copy_file_range) {
+		if (file_in->f_op->copy_file_range !=
+		    file_out->f_op->copy_file_range)
+			return -EXDEV;
+	} else if (file_in->f_op->remap_file_range) {
+		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+			return -EXDEV;
+	} else {
+                return -EOPNOTSUPP;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1511,11 +1508,14 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 			ret = cloned;
 			goto done;
 		}
+		/* Resort to copy_file_range if implemented. */
+		ret = -EOPNOTSUPP;
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+	if (file_out->f_op->copy_file_range)
+		ret = file_out->f_op->copy_file_range(file_in, pos_in,
+						      file_out, pos_out,
+						      len, flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);

Re: [PATCH v7] vfs: fix copy_file_range regression in cross-fs copies

[Nicolas Boichat]

On Mon, Feb 22, 2021 at 3:57 AM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>

Tested-by: Nicolas Boichat <drinkcat@chromium.org>

> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Changes since v6
> - restored i_sb checks for the clone operation
> Changes since v5
> - check if ->copy_file_range is NULL before calling it
> Changes since v4
> - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
>   or -EXDEV.
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks, implementing
>   Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c   |  8 +++++++-
>  fs/read_write.c | 50 ++++++++++++++++++++++++-------------------------
>  2 files changed, 32 insertions(+), 26 deletions(-)
> [snip]

[PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

A regression has been reported by Nicolas Boichat, found while using the
copy_file_range syscall to copy a tracefs file.  Before commit
5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
kernel would return -EXDEV to userspace when trying to copy a file across
different filesystems.  After this commit, the syscall doesn't fail anymore
and instead returns zero (zero bytes copied), as this file's content is
generated on-the-fly and thus reports a size of zero.

This patch restores some cross-filesystem copy restrictions that existed
prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
devices").  Filesystems are still allowed to fall-back to the VFS
generic_copy_file_range() implementation, but that has now to be done
explicitly.

nfsd is also modified to fall-back into generic_copy_file_range() in case
vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.

Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
Reported-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Luis Henriques <lhenriques@suse.de>
---
Changes since v7
- set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
  error returned is always related to the 'copy' operation
Changes since v6
- restored i_sb checks for the clone operation
Changes since v5
- check if ->copy_file_range is NULL before calling it
Changes since v4
- nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
  or -EXDEV.
Changes since v3
- dropped the COPY_FILE_SPLICE flag
- kept the f_op's checks early in generic_copy_file_checks, implementing
  Amir's suggestions
- modified nfsd to use generic_copy_file_range()
Changes since v2
- do all the required checks earlier, in generic_copy_file_checks(),
  adding new checks for ->remap_file_range
- new COPY_FILE_SPLICE flag
- don't remove filesystem's fallback to generic_copy_file_range()
- updated commit changelog (and subject)
Changes since v1 (after Amir review)
- restored do_copy_file_range() helper
- return -EOPNOTSUPP if fs doesn't implement CFR
- updated commit description

 fs/nfsd/vfs.c   |  8 +++++++-
 fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
 2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 04937e51de56..23dab0fa9087 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
 ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 			     u64 dst_pos, u64 count)
 {
+	ssize_t ret;
 
 	/*
 	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
@@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
 	 * limit like this and pipeline multiple COPY requests.
 	 */
 	count = min_t(u64, count, 1 << 22);
-	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
+
+	if (ret == -EOPNOTSUPP || ret == -EXDEV)
+		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
+					      count, 0);
+	return ret;
 }
 
 __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
diff --git a/fs/read_write.c b/fs/read_write.c
index 75f764b43418..5a26297fd410 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
 }
 EXPORT_SYMBOL(generic_copy_file_range);
 
-static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
-				  struct file *file_out, loff_t pos_out,
-				  size_t len, unsigned int flags)
-{
-	/*
-	 * Although we now allow filesystems to handle cross sb copy, passing
-	 * a file of the wrong filesystem type to filesystem driver can result
-	 * in an attempt to dereference the wrong type of ->private_data, so
-	 * avoid doing that until we really have a good reason.  NFS defines
-	 * several different file_system_type structures, but they all end up
-	 * using the same ->copy_file_range() function pointer.
-	 */
-	if (file_out->f_op->copy_file_range &&
-	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
-		return file_out->f_op->copy_file_range(file_in, pos_in,
-						       file_out, pos_out,
-						       len, flags);
-
-	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				       flags);
-}
-
 /*
  * Performs necessary checks before doing a file copy
  *
@@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
 	loff_t size_in;
 	int ret;
 
+	/*
+	 * Although we now allow filesystems to handle cross sb copy, passing
+	 * a file of the wrong filesystem type to filesystem driver can result
+	 * in an attempt to dereference the wrong type of ->private_data, so
+	 * avoid doing that until we really have a good reason.  NFS defines
+	 * several different file_system_type structures, but they all end up
+	 * using the same ->copy_file_range() function pointer.
+	 */
+	if (file_out->f_op->copy_file_range) {
+		if (file_in->f_op->copy_file_range !=
+		    file_out->f_op->copy_file_range)
+			return -EXDEV;
+	} else if (file_in->f_op->remap_file_range) {
+		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
+			return -EXDEV;
+	} else {
+                return -EOPNOTSUPP;
+	}
+
 	ret = generic_file_rw_checks(file_in, file_out);
 	if (ret)
 		return ret;
@@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 
 	file_start_write(file_out);
 
+	ret = -EOPNOTSUPP;
 	/*
 	 * Try cloning first, this is supported by more file systems, and
 	 * more efficient if both clone and copy are supported (e.g. NFS).
@@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
 		}
 	}
 
-	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-				flags);
-	WARN_ON_ONCE(ret == -EOPNOTSUPP);
+	if (file_out->f_op->copy_file_range)
+		ret = file_out->f_op->copy_file_range(file_in, pos_in,
+						      file_out, pos_out,
+						      len, flags);
 done:
 	if (ret > 0) {
 		fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Mon, Feb 22, 2021 at 12:23 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---

Reviewed-by: Amir Goldstein <amir73il@gmail.com>

Thanks,
Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[dai.ngo]

On 2/22/21 2:24 AM, Luis Henriques wrote:
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Changes since v7
> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
>    error returned is always related to the 'copy' operation
> Changes since v6
> - restored i_sb checks for the clone operation
> Changes since v5
> - check if ->copy_file_range is NULL before calling it
> Changes since v4
> - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
>    or -EXDEV.
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks, implementing
>    Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>    adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>   fs/nfsd/vfs.c   |  8 +++++++-
>   fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
>   2 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..23dab0fa9087 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
>   ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>   			     u64 dst_pos, u64 count)
>   {
> +	ssize_t ret;
>   
>   	/*
>   	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>   	 * limit like this and pipeline multiple COPY requests.
>   	 */
>   	count = min_t(u64, count, 1 << 22);
> -	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +
> +	if (ret == -EOPNOTSUPP || ret == -EXDEV)
> +		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> +					      count, 0);
> +	return ret;
>   }
>   
>   __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..5a26297fd410 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>   }
>   EXPORT_SYMBOL(generic_copy_file_range);
>   
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> -				  struct file *file_out, loff_t pos_out,
> -				  size_t len, unsigned int flags)
> -{
> -	/*
> -	 * Although we now allow filesystems to handle cross sb copy, passing
> -	 * a file of the wrong filesystem type to filesystem driver can result
> -	 * in an attempt to dereference the wrong type of ->private_data, so
> -	 * avoid doing that until we really have a good reason.  NFS defines
> -	 * several different file_system_type structures, but they all end up
> -	 * using the same ->copy_file_range() function pointer.
> -	 */
> -	if (file_out->f_op->copy_file_range &&
> -	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -		return file_out->f_op->copy_file_range(file_in, pos_in,
> -						       file_out, pos_out,
> -						       len, flags);
> -
> -	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -				       flags);
> -}
> -
>   /*
>    * Performs necessary checks before doing a file copy
>    *
> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>   	loff_t size_in;
>   	int ret;
>   
> +	/*
> +	 * Although we now allow filesystems to handle cross sb copy, passing
> +	 * a file of the wrong filesystem type to filesystem driver can result
> +	 * in an attempt to dereference the wrong type of ->private_data, so
> +	 * avoid doing that until we really have a good reason.  NFS defines
> +	 * several different file_system_type structures, but they all end up
> +	 * using the same ->copy_file_range() function pointer.
> +	 */
> +	if (file_out->f_op->copy_file_range) {
> +		if (file_in->f_op->copy_file_range !=
> +		    file_out->f_op->copy_file_range)
> +			return -EXDEV;
> +	} else if (file_in->f_op->remap_file_range) {
> +		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +			return -EXDEV;

I think this check is redundant, it's done in vfs_copy_file_range.
If this check is removed then the else clause below should be removed
also. Once this check and the else clause are removed then might as
well move the the check of copy_file_range from here to vfs_copy_file_range.

-Dai

> +	} else {
> +                return -EOPNOTSUPP;
> +	}
> +
>   	ret = generic_file_rw_checks(file_in, file_out);
>   	if (ret)
>   		return ret;
> @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>   
>   	file_start_write(file_out);
>   
> +	ret = -EOPNOTSUPP;
>   	/*
>   	 * Try cloning first, this is supported by more file systems, and
>   	 * more efficient if both clone and copy are supported (e.g. NFS).
> @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>   		}
>   	}
>   
> -	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -				flags);
> -	WARN_ON_ONCE(ret == -EOPNOTSUPP);
> +	if (file_out->f_op->copy_file_range)
> +		ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +						      file_out, pos_out,
> +						      len, flags);
>   done:
>   	if (ret > 0) {
>   		fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
> 
> On 2/22/21 2:24 AM, Luis Henriques wrote:
> > A regression has been reported by Nicolas Boichat, found while using the
> > copy_file_range syscall to copy a tracefs file.  Before commit
> > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > kernel would return -EXDEV to userspace when trying to copy a file across
> > different filesystems.  After this commit, the syscall doesn't fail anymore
> > and instead returns zero (zero bytes copied), as this file's content is
> > generated on-the-fly and thus reports a size of zero.
> > 
> > This patch restores some cross-filesystem copy restrictions that existed
> > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > devices").  Filesystems are still allowed to fall-back to the VFS
> > generic_copy_file_range() implementation, but that has now to be done
> > explicitly.
> > 
> > nfsd is also modified to fall-back into generic_copy_file_range() in case
> > vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> > 
> > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > ---
> > Changes since v7
> > - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
> >    error returned is always related to the 'copy' operation
> > Changes since v6
> > - restored i_sb checks for the clone operation
> > Changes since v5
> > - check if ->copy_file_range is NULL before calling it
> > Changes since v4
> > - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
> >    or -EXDEV.
> > Changes since v3
> > - dropped the COPY_FILE_SPLICE flag
> > - kept the f_op's checks early in generic_copy_file_checks, implementing
> >    Amir's suggestions
> > - modified nfsd to use generic_copy_file_range()
> > Changes since v2
> > - do all the required checks earlier, in generic_copy_file_checks(),
> >    adding new checks for ->remap_file_range
> > - new COPY_FILE_SPLICE flag
> > - don't remove filesystem's fallback to generic_copy_file_range()
> > - updated commit changelog (and subject)
> > Changes since v1 (after Amir review)
> > - restored do_copy_file_range() helper
> > - return -EOPNOTSUPP if fs doesn't implement CFR
> > - updated commit description
> > 
> >   fs/nfsd/vfs.c   |  8 +++++++-
> >   fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
> >   2 files changed, 31 insertions(+), 26 deletions(-)
> > 
> > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> > index 04937e51de56..23dab0fa9087 100644
> > --- a/fs/nfsd/vfs.c
> > +++ b/fs/nfsd/vfs.c
> > @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
> >   ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> >   			     u64 dst_pos, u64 count)
> >   {
> > +	ssize_t ret;
> >   	/*
> >   	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> > @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> >   	 * limit like this and pipeline multiple COPY requests.
> >   	 */
> >   	count = min_t(u64, count, 1 << 22);
> > -	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > +	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > +
> > +	if (ret == -EOPNOTSUPP || ret == -EXDEV)
> > +		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> > +					      count, 0);
> > +	return ret;
> >   }
> >   __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> > diff --git a/fs/read_write.c b/fs/read_write.c
> > index 75f764b43418..5a26297fd410 100644
> > --- a/fs/read_write.c
> > +++ b/fs/read_write.c
> > @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> >   }
> >   EXPORT_SYMBOL(generic_copy_file_range);
> > -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> > -				  struct file *file_out, loff_t pos_out,
> > -				  size_t len, unsigned int flags)
> > -{
> > -	/*
> > -	 * Although we now allow filesystems to handle cross sb copy, passing
> > -	 * a file of the wrong filesystem type to filesystem driver can result
> > -	 * in an attempt to dereference the wrong type of ->private_data, so
> > -	 * avoid doing that until we really have a good reason.  NFS defines
> > -	 * several different file_system_type structures, but they all end up
> > -	 * using the same ->copy_file_range() function pointer.
> > -	 */
> > -	if (file_out->f_op->copy_file_range &&
> > -	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> > -		return file_out->f_op->copy_file_range(file_in, pos_in,
> > -						       file_out, pos_out,
> > -						       len, flags);
> > -
> > -	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> > -				       flags);
> > -}
> > -
> >   /*
> >    * Performs necessary checks before doing a file copy
> >    *
> > @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
> >   	loff_t size_in;
> >   	int ret;
> > +	/*
> > +	 * Although we now allow filesystems to handle cross sb copy, passing
> > +	 * a file of the wrong filesystem type to filesystem driver can result
> > +	 * in an attempt to dereference the wrong type of ->private_data, so
> > +	 * avoid doing that until we really have a good reason.  NFS defines
> > +	 * several different file_system_type structures, but they all end up
> > +	 * using the same ->copy_file_range() function pointer.
> > +	 */
> > +	if (file_out->f_op->copy_file_range) {
> > +		if (file_in->f_op->copy_file_range !=
> > +		    file_out->f_op->copy_file_range)
> > +			return -EXDEV;
> > +	} else if (file_in->f_op->remap_file_range) {
> > +		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> > +			return -EXDEV;
> 
> I think this check is redundant, it's done in vfs_copy_file_range.
> If this check is removed then the else clause below should be removed
> also. Once this check and the else clause are removed then might as
> well move the the check of copy_file_range from here to vfs_copy_file_range.
> 

I don't think it's really redundant, although I agree is messy due to the
fact we try to clone first instead of copying them.

So, in the clone path, this is the only place where we return -EXDEV if:

1) we don't have ->copy_file_range *and*
2) we have ->remap_file_range but the i_sb are different.

The check in vfs_copy_file_range() is only executed if:

1) we have *valid* ->copy_file_range ops and/or
2) we have *valid* ->remap_file_range

So... if we remove the check in generic_copy_file_checks() as you suggest
and:
- we don't have ->copy_file_range,
- we have ->remap_file_range but
- the i_sb are different

we'll return the -EOPNOTSUPP (the one set in line "ret = -EOPNOTSUPP;" in
function vfs_copy_file_range() ) instead of -EXDEV.

But I may have got it all wrong.  I've looked so many times at this code
that I'm probably useless at finding problems in it :-)

Cheers,
--
Luís

> -Dai
> 
> > +	} else {
> > +                return -EOPNOTSUPP;
> > +	}
> > +
> >   	ret = generic_file_rw_checks(file_in, file_out);
> >   	if (ret)
> >   		return ret;
> > @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> >   	file_start_write(file_out);
> > +	ret = -EOPNOTSUPP;
> >   	/*
> >   	 * Try cloning first, this is supported by more file systems, and
> >   	 * more efficient if both clone and copy are supported (e.g. NFS).
> > @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> >   		}
> >   	}
> > -	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> > -				flags);
> > -	WARN_ON_ONCE(ret == -EOPNOTSUPP);
> > +	if (file_out->f_op->copy_file_range)
> > +		ret = file_out->f_op->copy_file_range(file_in, pos_in,
> > +						      file_out, pos_out,
> > +						      len, flags);
> >   done:
> >   	if (ret > 0) {
> >   		fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Tue, Feb 23, 2021 at 12:31 PM Luis Henriques <lhenriques@suse.de> wrote:
>
> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
> >
> > On 2/22/21 2:24 AM, Luis Henriques wrote:
> > > A regression has been reported by Nicolas Boichat, found while using the
> > > copy_file_range syscall to copy a tracefs file.  Before commit
> > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > > kernel would return -EXDEV to userspace when trying to copy a file across
> > > different filesystems.  After this commit, the syscall doesn't fail anymore
> > > and instead returns zero (zero bytes copied), as this file's content is
> > > generated on-the-fly and thus reports a size of zero.
> > >
> > > This patch restores some cross-filesystem copy restrictions that existed
> > > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > devices").  Filesystems are still allowed to fall-back to the VFS
> > > generic_copy_file_range() implementation, but that has now to be done
> > > explicitly.
> > >
> > > nfsd is also modified to fall-back into generic_copy_file_range() in case
> > > vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> > >
> > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> > > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> > > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> > > Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> > > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > > ---
> > > Changes since v7
> > > - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
> > >    error returned is always related to the 'copy' operation
> > > Changes since v6
> > > - restored i_sb checks for the clone operation
> > > Changes since v5
> > > - check if ->copy_file_range is NULL before calling it
> > > Changes since v4
> > > - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
> > >    or -EXDEV.
> > > Changes since v3
> > > - dropped the COPY_FILE_SPLICE flag
> > > - kept the f_op's checks early in generic_copy_file_checks, implementing
> > >    Amir's suggestions
> > > - modified nfsd to use generic_copy_file_range()
> > > Changes since v2
> > > - do all the required checks earlier, in generic_copy_file_checks(),
> > >    adding new checks for ->remap_file_range
> > > - new COPY_FILE_SPLICE flag
> > > - don't remove filesystem's fallback to generic_copy_file_range()
> > > - updated commit changelog (and subject)
> > > Changes since v1 (after Amir review)
> > > - restored do_copy_file_range() helper
> > > - return -EOPNOTSUPP if fs doesn't implement CFR
> > > - updated commit description
> > >
> > >   fs/nfsd/vfs.c   |  8 +++++++-
> > >   fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
> > >   2 files changed, 31 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> > > index 04937e51de56..23dab0fa9087 100644
> > > --- a/fs/nfsd/vfs.c
> > > +++ b/fs/nfsd/vfs.c
> > > @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
> > >   ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> > >                          u64 dst_pos, u64 count)
> > >   {
> > > +   ssize_t ret;
> > >     /*
> > >      * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> > > @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
> > >      * limit like this and pipeline multiple COPY requests.
> > >      */
> > >     count = min_t(u64, count, 1 << 22);
> > > -   return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > > +   ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > > +
> > > +   if (ret == -EOPNOTSUPP || ret == -EXDEV)
> > > +           ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> > > +                                         count, 0);
> > > +   return ret;
> > >   }
> > >   __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> > > diff --git a/fs/read_write.c b/fs/read_write.c
> > > index 75f764b43418..5a26297fd410 100644
> > > --- a/fs/read_write.c
> > > +++ b/fs/read_write.c
> > > @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
> > >   }
> > >   EXPORT_SYMBOL(generic_copy_file_range);
> > > -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> > > -                             struct file *file_out, loff_t pos_out,
> > > -                             size_t len, unsigned int flags)
> > > -{
> > > -   /*
> > > -    * Although we now allow filesystems to handle cross sb copy, passing
> > > -    * a file of the wrong filesystem type to filesystem driver can result
> > > -    * in an attempt to dereference the wrong type of ->private_data, so
> > > -    * avoid doing that until we really have a good reason.  NFS defines
> > > -    * several different file_system_type structures, but they all end up
> > > -    * using the same ->copy_file_range() function pointer.
> > > -    */
> > > -   if (file_out->f_op->copy_file_range &&
> > > -       file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> > > -           return file_out->f_op->copy_file_range(file_in, pos_in,
> > > -                                                  file_out, pos_out,
> > > -                                                  len, flags);
> > > -
> > > -   return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> > > -                                  flags);
> > > -}
> > > -
> > >   /*
> > >    * Performs necessary checks before doing a file copy
> > >    *
> > > @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
> > >     loff_t size_in;
> > >     int ret;
> > > +   /*
> > > +    * Although we now allow filesystems to handle cross sb copy, passing
> > > +    * a file of the wrong filesystem type to filesystem driver can result
> > > +    * in an attempt to dereference the wrong type of ->private_data, so
> > > +    * avoid doing that until we really have a good reason.  NFS defines
> > > +    * several different file_system_type structures, but they all end up
> > > +    * using the same ->copy_file_range() function pointer.
> > > +    */
> > > +   if (file_out->f_op->copy_file_range) {
> > > +           if (file_in->f_op->copy_file_range !=
> > > +               file_out->f_op->copy_file_range)
> > > +                   return -EXDEV;
> > > +   } else if (file_in->f_op->remap_file_range) {
> > > +           if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> > > +                   return -EXDEV;
> >
> > I think this check is redundant, it's done in vfs_copy_file_range.
> > If this check is removed then the else clause below should be removed
> > also. Once this check and the else clause are removed then might as
> > well move the the check of copy_file_range from here to vfs_copy_file_range.
> >
>
> I don't think it's really redundant, although I agree is messy due to the
> fact we try to clone first instead of copying them.
>

It was put here in early checks on purpose before the check for
zero size file.
I'm pretty sure this wasn't the case in earlier versions of the path
and then it did not solve the reported problem.

Thanks,
Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[dai.ngo]

On 2/23/21 2:32 AM, Luis Henriques wrote:
> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
>> On 2/22/21 2:24 AM, Luis Henriques wrote:
>>> A regression has been reported by Nicolas Boichat, found while using the
>>> copy_file_range syscall to copy a tracefs file.  Before commit
>>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
>>> kernel would return -EXDEV to userspace when trying to copy a file across
>>> different filesystems.  After this commit, the syscall doesn't fail anymore
>>> and instead returns zero (zero bytes copied), as this file's content is
>>> generated on-the-fly and thus reports a size of zero.
>>>
>>> This patch restores some cross-filesystem copy restrictions that existed
>>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>>> devices").  Filesystems are still allowed to fall-back to the VFS
>>> generic_copy_file_range() implementation, but that has now to be done
>>> explicitly.
>>>
>>> nfsd is also modified to fall-back into generic_copy_file_range() in case
>>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>>>
>>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
>>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
>>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>>> ---
>>> Changes since v7
>>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
>>>     error returned is always related to the 'copy' operation
>>> Changes since v6
>>> - restored i_sb checks for the clone operation
>>> Changes since v5
>>> - check if ->copy_file_range is NULL before calling it
>>> Changes since v4
>>> - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
>>>     or -EXDEV.
>>> Changes since v3
>>> - dropped the COPY_FILE_SPLICE flag
>>> - kept the f_op's checks early in generic_copy_file_checks, implementing
>>>     Amir's suggestions
>>> - modified nfsd to use generic_copy_file_range()
>>> Changes since v2
>>> - do all the required checks earlier, in generic_copy_file_checks(),
>>>     adding new checks for ->remap_file_range
>>> - new COPY_FILE_SPLICE flag
>>> - don't remove filesystem's fallback to generic_copy_file_range()
>>> - updated commit changelog (and subject)
>>> Changes since v1 (after Amir review)
>>> - restored do_copy_file_range() helper
>>> - return -EOPNOTSUPP if fs doesn't implement CFR
>>> - updated commit description
>>>
>>>    fs/nfsd/vfs.c   |  8 +++++++-
>>>    fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
>>>    2 files changed, 31 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
>>> index 04937e51de56..23dab0fa9087 100644
>>> --- a/fs/nfsd/vfs.c
>>> +++ b/fs/nfsd/vfs.c
>>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
>>>    ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>>>    			     u64 dst_pos, u64 count)
>>>    {
>>> +	ssize_t ret;
>>>    	/*
>>>    	 * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>>>    	 * limit like this and pipeline multiple COPY requests.
>>>    	 */
>>>    	count = min_t(u64, count, 1 << 22);
>>> -	return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>> +	ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>> +
>>> +	if (ret == -EOPNOTSUPP || ret == -EXDEV)
>>> +		ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
>>> +					      count, 0);
>>> +	return ret;
>>>    }
>>>    __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
>>> diff --git a/fs/read_write.c b/fs/read_write.c
>>> index 75f764b43418..5a26297fd410 100644
>>> --- a/fs/read_write.c
>>> +++ b/fs/read_write.c
>>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>>>    }
>>>    EXPORT_SYMBOL(generic_copy_file_range);
>>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
>>> -				  struct file *file_out, loff_t pos_out,
>>> -				  size_t len, unsigned int flags)
>>> -{
>>> -	/*
>>> -	 * Although we now allow filesystems to handle cross sb copy, passing
>>> -	 * a file of the wrong filesystem type to filesystem driver can result
>>> -	 * in an attempt to dereference the wrong type of ->private_data, so
>>> -	 * avoid doing that until we really have a good reason.  NFS defines
>>> -	 * several different file_system_type structures, but they all end up
>>> -	 * using the same ->copy_file_range() function pointer.
>>> -	 */
>>> -	if (file_out->f_op->copy_file_range &&
>>> -	    file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
>>> -		return file_out->f_op->copy_file_range(file_in, pos_in,
>>> -						       file_out, pos_out,
>>> -						       len, flags);
>>> -
>>> -	return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>>> -				       flags);
>>> -}
>>> -
>>>    /*
>>>     * Performs necessary checks before doing a file copy
>>>     *
>>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>>>    	loff_t size_in;
>>>    	int ret;
>>> +	/*
>>> +	 * Although we now allow filesystems to handle cross sb copy, passing
>>> +	 * a file of the wrong filesystem type to filesystem driver can result
>>> +	 * in an attempt to dereference the wrong type of ->private_data, so
>>> +	 * avoid doing that until we really have a good reason.  NFS defines
>>> +	 * several different file_system_type structures, but they all end up
>>> +	 * using the same ->copy_file_range() function pointer.
>>> +	 */
>>> +	if (file_out->f_op->copy_file_range) {
>>> +		if (file_in->f_op->copy_file_range !=
>>> +		    file_out->f_op->copy_file_range)
>>> +			return -EXDEV;
>>> +	} else if (file_in->f_op->remap_file_range) {
>>> +		if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>>> +			return -EXDEV;
>> I think this check is redundant, it's done in vfs_copy_file_range.
>> If this check is removed then the else clause below should be removed
>> also. Once this check and the else clause are removed then might as
>> well move the the check of copy_file_range from here to vfs_copy_file_range.
>>
> I don't think it's really redundant, although I agree is messy due to the
> fact we try to clone first instead of copying them.
>
> So, in the clone path, this is the only place where we return -EXDEV if:
>
> 1) we don't have ->copy_file_range *and*
> 2) we have ->remap_file_range but the i_sb are different.
>
> The check in vfs_copy_file_range() is only executed if:
>
> 1) we have *valid* ->copy_file_range ops and/or
> 2) we have *valid* ->remap_file_range
>
> So... if we remove the check in generic_copy_file_checks() as you suggest
> and:
> - we don't have ->copy_file_range,
> - we have ->remap_file_range but
> - the i_sb are different
>
> we'll return the -EOPNOTSUPP (the one set in line "ret = -EOPNOTSUPP;" in
> function vfs_copy_file_range() ) instead of -EXDEV.

Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
-EXDEVV by doing generic_copy_file_range.  Do any other consumers of
vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
the correct error code for this case? It seems to me that -EOPNOTSUPP
is more appropriate than EXDEV when (sb1 != sb2).

>
> But I may have got it all wrong.  I've looked so many times at this code
> that I'm probably useless at finding problems in it :-)

You're not alone, we all try to do the right thing :-)

-Dai

>
> Cheers,
> --
> Luís
>
>> -Dai
>>
>>> +	} else {
>>> +                return -EOPNOTSUPP;
>>> +	}
>>> +
>>>    	ret = generic_file_rw_checks(file_in, file_out);
>>>    	if (ret)
>>>    		return ret;
>>> @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>>>    	file_start_write(file_out);
>>> +	ret = -EOPNOTSUPP;
>>>    	/*
>>>    	 * Try cloning first, this is supported by more file systems, and
>>>    	 * more efficient if both clone and copy are supported (e.g. NFS).
>>> @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>>>    		}
>>>    	}
>>> -	ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>>> -				flags);
>>> -	WARN_ON_ONCE(ret == -EOPNOTSUPP);
>>> +	if (file_out->f_op->copy_file_range)
>>> +		ret = file_out->f_op->copy_file_range(file_in, pos_in,
>>> +						      file_out, pos_out,
>>> +						      len, flags);
>>>    done:
>>>    	if (ret > 0) {
>>>    		fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[dai.ngo]

On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
>
> On 2/23/21 2:32 AM, Luis Henriques wrote:
>> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
>>> On 2/22/21 2:24 AM, Luis Henriques wrote:
>>>> A regression has been reported by Nicolas Boichat, found while 
>>>> using the
>>>> copy_file_range syscall to copy a tracefs file.  Before commit
>>>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
>>>> kernel would return -EXDEV to userspace when trying to copy a file 
>>>> across
>>>> different filesystems.  After this commit, the syscall doesn't fail 
>>>> anymore
>>>> and instead returns zero (zero bytes copied), as this file's 
>>>> content is
>>>> generated on-the-fly and thus reports a size of zero.
>>>>
>>>> This patch restores some cross-filesystem copy restrictions that 
>>>> existed
>>>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy 
>>>> across
>>>> devices").  Filesystems are still allowed to fall-back to the VFS
>>>> generic_copy_file_range() implementation, but that has now to be done
>>>> explicitly.
>>>>
>>>> nfsd is also modified to fall-back into generic_copy_file_range() 
>>>> in case
>>>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>>>>
>>>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across 
>>>> devices")
>>>> Link: 
>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
>>>> Link: 
>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
>>>> Link: 
>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
>>>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
>>>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>>>> ---
>>>> Changes since v7
>>>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so 
>>>> that the
>>>>     error returned is always related to the 'copy' operation
>>>> Changes since v6
>>>> - restored i_sb checks for the clone operation
>>>> Changes since v5
>>>> - check if ->copy_file_range is NULL before calling it
>>>> Changes since v4
>>>> - nfsd falls-back to generic_copy_file_range() only *if* it gets 
>>>> -EOPNOTSUPP
>>>>     or -EXDEV.
>>>> Changes since v3
>>>> - dropped the COPY_FILE_SPLICE flag
>>>> - kept the f_op's checks early in generic_copy_file_checks, 
>>>> implementing
>>>>     Amir's suggestions
>>>> - modified nfsd to use generic_copy_file_range()
>>>> Changes since v2
>>>> - do all the required checks earlier, in generic_copy_file_checks(),
>>>>     adding new checks for ->remap_file_range
>>>> - new COPY_FILE_SPLICE flag
>>>> - don't remove filesystem's fallback to generic_copy_file_range()
>>>> - updated commit changelog (and subject)
>>>> Changes since v1 (after Amir review)
>>>> - restored do_copy_file_range() helper
>>>> - return -EOPNOTSUPP if fs doesn't implement CFR
>>>> - updated commit description
>>>>
>>>>    fs/nfsd/vfs.c   |  8 +++++++-
>>>>    fs/read_write.c | 49 
>>>> ++++++++++++++++++++++++-------------------------
>>>>    2 files changed, 31 insertions(+), 26 deletions(-)
>>>>
>>>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
>>>> index 04937e51de56..23dab0fa9087 100644
>>>> --- a/fs/nfsd/vfs.c
>>>> +++ b/fs/nfsd/vfs.c
>>>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file 
>>>> *nf_src, u64 src_pos,
>>>>    ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, 
>>>> struct file *dst,
>>>>                     u64 dst_pos, u64 count)
>>>>    {
>>>> +    ssize_t ret;
>>>>        /*
>>>>         * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>>>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, 
>>>> u64 src_pos, struct file *dst,
>>>>         * limit like this and pipeline multiple COPY requests.
>>>>         */
>>>>        count = min_t(u64, count, 1 << 22);
>>>> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>>> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>>> +
>>>> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
>>>> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
>>>> +                          count, 0);
>>>> +    return ret;
>>>>    }
>>>>    __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh 
>>>> *fhp,
>>>> diff --git a/fs/read_write.c b/fs/read_write.c
>>>> index 75f764b43418..5a26297fd410 100644
>>>> --- a/fs/read_write.c
>>>> +++ b/fs/read_write.c
>>>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file 
>>>> *file_in, loff_t pos_in,
>>>>    }
>>>>    EXPORT_SYMBOL(generic_copy_file_range);
>>>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t 
>>>> pos_in,
>>>> -                  struct file *file_out, loff_t pos_out,
>>>> -                  size_t len, unsigned int flags)
>>>> -{
>>>> -    /*
>>>> -     * Although we now allow filesystems to handle cross sb copy, 
>>>> passing
>>>> -     * a file of the wrong filesystem type to filesystem driver 
>>>> can result
>>>> -     * in an attempt to dereference the wrong type of 
>>>> ->private_data, so
>>>> -     * avoid doing that until we really have a good reason.  NFS 
>>>> defines
>>>> -     * several different file_system_type structures, but they all 
>>>> end up
>>>> -     * using the same ->copy_file_range() function pointer.
>>>> -     */
>>>> -    if (file_out->f_op->copy_file_range &&
>>>> -        file_out->f_op->copy_file_range == 
>>>> file_in->f_op->copy_file_range)
>>>> -        return file_out->f_op->copy_file_range(file_in, pos_in,
>>>> -                               file_out, pos_out,
>>>> -                               len, flags);
>>>> -
>>>> -    return generic_copy_file_range(file_in, pos_in, file_out, 
>>>> pos_out, len,
>>>> -                       flags);
>>>> -}
>>>> -
>>>>    /*
>>>>     * Performs necessary checks before doing a file copy
>>>>     *
>>>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct 
>>>> file *file_in, loff_t pos_in,
>>>>        loff_t size_in;
>>>>        int ret;
>>>> +    /*
>>>> +     * Although we now allow filesystems to handle cross sb copy, 
>>>> passing
>>>> +     * a file of the wrong filesystem type to filesystem driver 
>>>> can result
>>>> +     * in an attempt to dereference the wrong type of 
>>>> ->private_data, so
>>>> +     * avoid doing that until we really have a good reason.  NFS 
>>>> defines
>>>> +     * several different file_system_type structures, but they all 
>>>> end up
>>>> +     * using the same ->copy_file_range() function pointer.
>>>> +     */
>>>> +    if (file_out->f_op->copy_file_range) {
>>>> +        if (file_in->f_op->copy_file_range !=
>>>> +            file_out->f_op->copy_file_range)
>>>> +            return -EXDEV;
>>>> +    } else if (file_in->f_op->remap_file_range) {
>>>> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>>>> +            return -EXDEV;
>>> I think this check is redundant, it's done in vfs_copy_file_range.
>>> If this check is removed then the else clause below should be removed
>>> also. Once this check and the else clause are removed then might as
>>> well move the the check of copy_file_range from here to 
>>> vfs_copy_file_range.
>>>
>> I don't think it's really redundant, although I agree is messy due to 
>> the
>> fact we try to clone first instead of copying them.
>>
>> So, in the clone path, this is the only place where we return -EXDEV if:
>>
>> 1) we don't have ->copy_file_range *and*
>> 2) we have ->remap_file_range but the i_sb are different.
>>
>> The check in vfs_copy_file_range() is only executed if:
>>
>> 1) we have *valid* ->copy_file_range ops and/or
>> 2) we have *valid* ->remap_file_range
>>
>> So... if we remove the check in generic_copy_file_checks() as you 
>> suggest
>> and:
>> - we don't have ->copy_file_range,
>> - we have ->remap_file_range but
>> - the i_sb are different
>>
>> we'll return the -EOPNOTSUPP (the one set in line "ret = 
>> -EOPNOTSUPP;" in
>> function vfs_copy_file_range() ) instead of -EXDEV.
>
> Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
> -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
> vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
> the correct error code for this case? It seems to me that -EOPNOTSUPP
> is more appropriate than EXDEV when (sb1 != sb2).

So with the current patch, for a clone operation across 2 filesystems:

   . if src and dst filesystem support both copy_file_range and
     map_file_range then the code returns -ENOTSUPPORT.

   . if the filesystems only support map_file_range then the
     code returns -EXDEV

This seems confusing, shouldn't only 1 error code returned for this case?

-Dai

>
>>
>> But I may have got it all wrong.  I've looked so many times at this code
>> that I'm probably useless at finding problems in it :-)
>
> You're not alone, we all try to do the right thing :-)
>
> -Dai
>
>>
>> Cheers,
>> -- 
>> Luís
>>
>>> -Dai
>>>
>>>> +    } else {
>>>> +                return -EOPNOTSUPP;
>>>> +    }
>>>> +
>>>>        ret = generic_file_rw_checks(file_in, file_out);
>>>>        if (ret)
>>>>            return ret;
>>>> @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file 
>>>> *file_in, loff_t pos_in,
>>>>        file_start_write(file_out);
>>>> +    ret = -EOPNOTSUPP;
>>>>        /*
>>>>         * Try cloning first, this is supported by more file 
>>>> systems, and
>>>>         * more efficient if both clone and copy are supported (e.g. 
>>>> NFS).
>>>> @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file 
>>>> *file_in, loff_t pos_in,
>>>>            }
>>>>        }
>>>> -    ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
>>>> -                flags);
>>>> -    WARN_ON_ONCE(ret == -EOPNOTSUPP);
>>>> +    if (file_out->f_op->copy_file_range)
>>>> +        ret = file_out->f_op->copy_file_range(file_in, pos_in,
>>>> +                              file_out, pos_out,
>>>> +                              len, flags);
>>>>    done:
>>>>        if (ret > 0) {
>>>>            fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Tue, Feb 23, 2021 at 6:02 PM <dai.ngo@oracle.com> wrote:
>
>
> On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
> >
> > On 2/23/21 2:32 AM, Luis Henriques wrote:
> >> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
> >>> On 2/22/21 2:24 AM, Luis Henriques wrote:
> >>>> A regression has been reported by Nicolas Boichat, found while
> >>>> using the
> >>>> copy_file_range syscall to copy a tracefs file.  Before commit
> >>>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> >>>> kernel would return -EXDEV to userspace when trying to copy a file
> >>>> across
> >>>> different filesystems.  After this commit, the syscall doesn't fail
> >>>> anymore
> >>>> and instead returns zero (zero bytes copied), as this file's
> >>>> content is
> >>>> generated on-the-fly and thus reports a size of zero.
> >>>>
> >>>> This patch restores some cross-filesystem copy restrictions that
> >>>> existed
> >>>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
> >>>> across
> >>>> devices").  Filesystems are still allowed to fall-back to the VFS
> >>>> generic_copy_file_range() implementation, but that has now to be done
> >>>> explicitly.
> >>>>
> >>>> nfsd is also modified to fall-back into generic_copy_file_range()
> >>>> in case
> >>>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> >>>>
> >>>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >>>> devices")
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> >>>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> >>>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> >>>> ---
> >>>> Changes since v7
> >>>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
> >>>> that the
> >>>>     error returned is always related to the 'copy' operation
> >>>> Changes since v6
> >>>> - restored i_sb checks for the clone operation
> >>>> Changes since v5
> >>>> - check if ->copy_file_range is NULL before calling it
> >>>> Changes since v4
> >>>> - nfsd falls-back to generic_copy_file_range() only *if* it gets
> >>>> -EOPNOTSUPP
> >>>>     or -EXDEV.
> >>>> Changes since v3
> >>>> - dropped the COPY_FILE_SPLICE flag
> >>>> - kept the f_op's checks early in generic_copy_file_checks,
> >>>> implementing
> >>>>     Amir's suggestions
> >>>> - modified nfsd to use generic_copy_file_range()
> >>>> Changes since v2
> >>>> - do all the required checks earlier, in generic_copy_file_checks(),
> >>>>     adding new checks for ->remap_file_range
> >>>> - new COPY_FILE_SPLICE flag
> >>>> - don't remove filesystem's fallback to generic_copy_file_range()
> >>>> - updated commit changelog (and subject)
> >>>> Changes since v1 (after Amir review)
> >>>> - restored do_copy_file_range() helper
> >>>> - return -EOPNOTSUPP if fs doesn't implement CFR
> >>>> - updated commit description
> >>>>
> >>>>    fs/nfsd/vfs.c   |  8 +++++++-
> >>>>    fs/read_write.c | 49
> >>>> ++++++++++++++++++++++++-------------------------
> >>>>    2 files changed, 31 insertions(+), 26 deletions(-)
> >>>>
> >>>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> >>>> index 04937e51de56..23dab0fa9087 100644
> >>>> --- a/fs/nfsd/vfs.c
> >>>> +++ b/fs/nfsd/vfs.c
> >>>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
> >>>> *nf_src, u64 src_pos,
> >>>>    ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
> >>>> struct file *dst,
> >>>>                     u64 dst_pos, u64 count)
> >>>>    {
> >>>> +    ssize_t ret;
> >>>>        /*
> >>>>         * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> >>>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
> >>>> u64 src_pos, struct file *dst,
> >>>>         * limit like this and pipeline multiple COPY requests.
> >>>>         */
> >>>>        count = min_t(u64, count, 1 << 22);
> >>>> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >>>> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >>>> +
> >>>> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
> >>>> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> >>>> +                          count, 0);
> >>>> +    return ret;
> >>>>    }
> >>>>    __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
> >>>> *fhp,
> >>>> diff --git a/fs/read_write.c b/fs/read_write.c
> >>>> index 75f764b43418..5a26297fd410 100644
> >>>> --- a/fs/read_write.c
> >>>> +++ b/fs/read_write.c
> >>>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
> >>>> *file_in, loff_t pos_in,
> >>>>    }
> >>>>    EXPORT_SYMBOL(generic_copy_file_range);
> >>>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t
> >>>> pos_in,
> >>>> -                  struct file *file_out, loff_t pos_out,
> >>>> -                  size_t len, unsigned int flags)
> >>>> -{
> >>>> -    /*
> >>>> -     * Although we now allow filesystems to handle cross sb copy,
> >>>> passing
> >>>> -     * a file of the wrong filesystem type to filesystem driver
> >>>> can result
> >>>> -     * in an attempt to dereference the wrong type of
> >>>> ->private_data, so
> >>>> -     * avoid doing that until we really have a good reason.  NFS
> >>>> defines
> >>>> -     * several different file_system_type structures, but they all
> >>>> end up
> >>>> -     * using the same ->copy_file_range() function pointer.
> >>>> -     */
> >>>> -    if (file_out->f_op->copy_file_range &&
> >>>> -        file_out->f_op->copy_file_range ==
> >>>> file_in->f_op->copy_file_range)
> >>>> -        return file_out->f_op->copy_file_range(file_in, pos_in,
> >>>> -                               file_out, pos_out,
> >>>> -                               len, flags);
> >>>> -
> >>>> -    return generic_copy_file_range(file_in, pos_in, file_out,
> >>>> pos_out, len,
> >>>> -                       flags);
> >>>> -}
> >>>> -
> >>>>    /*
> >>>>     * Performs necessary checks before doing a file copy
> >>>>     *
> >>>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
> >>>> file *file_in, loff_t pos_in,
> >>>>        loff_t size_in;
> >>>>        int ret;
> >>>> +    /*
> >>>> +     * Although we now allow filesystems to handle cross sb copy,
> >>>> passing
> >>>> +     * a file of the wrong filesystem type to filesystem driver
> >>>> can result
> >>>> +     * in an attempt to dereference the wrong type of
> >>>> ->private_data, so
> >>>> +     * avoid doing that until we really have a good reason.  NFS
> >>>> defines
> >>>> +     * several different file_system_type structures, but they all
> >>>> end up
> >>>> +     * using the same ->copy_file_range() function pointer.
> >>>> +     */
> >>>> +    if (file_out->f_op->copy_file_range) {
> >>>> +        if (file_in->f_op->copy_file_range !=
> >>>> +            file_out->f_op->copy_file_range)
> >>>> +            return -EXDEV;
> >>>> +    } else if (file_in->f_op->remap_file_range) {
> >>>> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >>>> +            return -EXDEV;
> >>> I think this check is redundant, it's done in vfs_copy_file_range.
> >>> If this check is removed then the else clause below should be removed
> >>> also. Once this check and the else clause are removed then might as
> >>> well move the the check of copy_file_range from here to
> >>> vfs_copy_file_range.
> >>>
> >> I don't think it's really redundant, although I agree is messy due to
> >> the
> >> fact we try to clone first instead of copying them.
> >>
> >> So, in the clone path, this is the only place where we return -EXDEV if:
> >>
> >> 1) we don't have ->copy_file_range *and*
> >> 2) we have ->remap_file_range but the i_sb are different.
> >>
> >> The check in vfs_copy_file_range() is only executed if:
> >>
> >> 1) we have *valid* ->copy_file_range ops and/or
> >> 2) we have *valid* ->remap_file_range
> >>
> >> So... if we remove the check in generic_copy_file_checks() as you
> >> suggest
> >> and:
> >> - we don't have ->copy_file_range,
> >> - we have ->remap_file_range but
> >> - the i_sb are different
> >>
> >> we'll return the -EOPNOTSUPP (the one set in line "ret =
> >> -EOPNOTSUPP;" in
> >> function vfs_copy_file_range() ) instead of -EXDEV.
> >
> > Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
> > -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
> > vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
> > the correct error code for this case? It seems to me that -EOPNOTSUPP
> > is more appropriate than EXDEV when (sb1 != sb2).
>

EXDEV is the right code for:
filesystem supports the operation but not for sb1 != sb1.

> So with the current patch, for a clone operation across 2 filesystems:
>
>    . if src and dst filesystem support both copy_file_range and
>      map_file_range then the code returns -ENOTSUPPORT.
>

Why do you say that?
Which code are you referring to exactly?
Did you see this behavior in a test?

>    . if the filesystems only support map_file_range then the
>      code returns -EXDEV
>
> This seems confusing, shouldn't only 1 error code returned for this case?
>

From my read of the code, user will get -EXDEV in both the cases you
listed.

Thanks,
Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[dai.ngo]

On 2/23/21 8:47 AM, Amir Goldstein wrote:
> On Tue, Feb 23, 2021 at 6:02 PM <dai.ngo@oracle.com> wrote:
>>
>> On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
>>> On 2/23/21 2:32 AM, Luis Henriques wrote:
>>>> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
>>>>> On 2/22/21 2:24 AM, Luis Henriques wrote:
>>>>>> A regression has been reported by Nicolas Boichat, found while
>>>>>> using the
>>>>>> copy_file_range syscall to copy a tracefs file.  Before commit
>>>>>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
>>>>>> kernel would return -EXDEV to userspace when trying to copy a file
>>>>>> across
>>>>>> different filesystems.  After this commit, the syscall doesn't fail
>>>>>> anymore
>>>>>> and instead returns zero (zero bytes copied), as this file's
>>>>>> content is
>>>>>> generated on-the-fly and thus reports a size of zero.
>>>>>>
>>>>>> This patch restores some cross-filesystem copy restrictions that
>>>>>> existed
>>>>>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
>>>>>> across
>>>>>> devices").  Filesystems are still allowed to fall-back to the VFS
>>>>>> generic_copy_file_range() implementation, but that has now to be done
>>>>>> explicitly.
>>>>>>
>>>>>> nfsd is also modified to fall-back into generic_copy_file_range()
>>>>>> in case
>>>>>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>>>>>>
>>>>>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>>>>>> devices")
>>>>>> Link:
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
>>>>>> Link:
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
>>>>>> Link:
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
>>>>>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
>>>>>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>>>>>> ---
>>>>>> Changes since v7
>>>>>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
>>>>>> that the
>>>>>>      error returned is always related to the 'copy' operation
>>>>>> Changes since v6
>>>>>> - restored i_sb checks for the clone operation
>>>>>> Changes since v5
>>>>>> - check if ->copy_file_range is NULL before calling it
>>>>>> Changes since v4
>>>>>> - nfsd falls-back to generic_copy_file_range() only *if* it gets
>>>>>> -EOPNOTSUPP
>>>>>>      or -EXDEV.
>>>>>> Changes since v3
>>>>>> - dropped the COPY_FILE_SPLICE flag
>>>>>> - kept the f_op's checks early in generic_copy_file_checks,
>>>>>> implementing
>>>>>>      Amir's suggestions
>>>>>> - modified nfsd to use generic_copy_file_range()
>>>>>> Changes since v2
>>>>>> - do all the required checks earlier, in generic_copy_file_checks(),
>>>>>>      adding new checks for ->remap_file_range
>>>>>> - new COPY_FILE_SPLICE flag
>>>>>> - don't remove filesystem's fallback to generic_copy_file_range()
>>>>>> - updated commit changelog (and subject)
>>>>>> Changes since v1 (after Amir review)
>>>>>> - restored do_copy_file_range() helper
>>>>>> - return -EOPNOTSUPP if fs doesn't implement CFR
>>>>>> - updated commit description
>>>>>>
>>>>>>     fs/nfsd/vfs.c   |  8 +++++++-
>>>>>>     fs/read_write.c | 49
>>>>>> ++++++++++++++++++++++++-------------------------
>>>>>>     2 files changed, 31 insertions(+), 26 deletions(-)
>>>>>>
>>>>>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
>>>>>> index 04937e51de56..23dab0fa9087 100644
>>>>>> --- a/fs/nfsd/vfs.c
>>>>>> +++ b/fs/nfsd/vfs.c
>>>>>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
>>>>>> *nf_src, u64 src_pos,
>>>>>>     ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
>>>>>> struct file *dst,
>>>>>>                      u64 dst_pos, u64 count)
>>>>>>     {
>>>>>> +    ssize_t ret;
>>>>>>         /*
>>>>>>          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>>>>>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
>>>>>> u64 src_pos, struct file *dst,
>>>>>>          * limit like this and pipeline multiple COPY requests.
>>>>>>          */
>>>>>>         count = min_t(u64, count, 1 << 22);
>>>>>> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>>>>> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>>>>>> +
>>>>>> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
>>>>>> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
>>>>>> +                          count, 0);
>>>>>> +    return ret;
>>>>>>     }
>>>>>>     __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
>>>>>> *fhp,
>>>>>> diff --git a/fs/read_write.c b/fs/read_write.c
>>>>>> index 75f764b43418..5a26297fd410 100644
>>>>>> --- a/fs/read_write.c
>>>>>> +++ b/fs/read_write.c
>>>>>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
>>>>>> *file_in, loff_t pos_in,
>>>>>>     }
>>>>>>     EXPORT_SYMBOL(generic_copy_file_range);
>>>>>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t
>>>>>> pos_in,
>>>>>> -                  struct file *file_out, loff_t pos_out,
>>>>>> -                  size_t len, unsigned int flags)
>>>>>> -{
>>>>>> -    /*
>>>>>> -     * Although we now allow filesystems to handle cross sb copy,
>>>>>> passing
>>>>>> -     * a file of the wrong filesystem type to filesystem driver
>>>>>> can result
>>>>>> -     * in an attempt to dereference the wrong type of
>>>>>> ->private_data, so
>>>>>> -     * avoid doing that until we really have a good reason.  NFS
>>>>>> defines
>>>>>> -     * several different file_system_type structures, but they all
>>>>>> end up
>>>>>> -     * using the same ->copy_file_range() function pointer.
>>>>>> -     */
>>>>>> -    if (file_out->f_op->copy_file_range &&
>>>>>> -        file_out->f_op->copy_file_range ==
>>>>>> file_in->f_op->copy_file_range)
>>>>>> -        return file_out->f_op->copy_file_range(file_in, pos_in,
>>>>>> -                               file_out, pos_out,
>>>>>> -                               len, flags);
>>>>>> -
>>>>>> -    return generic_copy_file_range(file_in, pos_in, file_out,
>>>>>> pos_out, len,
>>>>>> -                       flags);
>>>>>> -}
>>>>>> -
>>>>>>     /*
>>>>>>      * Performs necessary checks before doing a file copy
>>>>>>      *
>>>>>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
>>>>>> file *file_in, loff_t pos_in,
>>>>>>         loff_t size_in;
>>>>>>         int ret;
>>>>>> +    /*
>>>>>> +     * Although we now allow filesystems to handle cross sb copy,
>>>>>> passing
>>>>>> +     * a file of the wrong filesystem type to filesystem driver
>>>>>> can result
>>>>>> +     * in an attempt to dereference the wrong type of
>>>>>> ->private_data, so
>>>>>> +     * avoid doing that until we really have a good reason.  NFS
>>>>>> defines
>>>>>> +     * several different file_system_type structures, but they all
>>>>>> end up
>>>>>> +     * using the same ->copy_file_range() function pointer.
>>>>>> +     */
>>>>>> +    if (file_out->f_op->copy_file_range) {
>>>>>> +        if (file_in->f_op->copy_file_range !=
>>>>>> +            file_out->f_op->copy_file_range)
>>>>>> +            return -EXDEV;
>>>>>> +    } else if (file_in->f_op->remap_file_range) {
>>>>>> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>>>>>> +            return -EXDEV;
>>>>> I think this check is redundant, it's done in vfs_copy_file_range.
>>>>> If this check is removed then the else clause below should be removed
>>>>> also. Once this check and the else clause are removed then might as
>>>>> well move the the check of copy_file_range from here to
>>>>> vfs_copy_file_range.
>>>>>
>>>> I don't think it's really redundant, although I agree is messy due to
>>>> the
>>>> fact we try to clone first instead of copying them.
>>>>
>>>> So, in the clone path, this is the only place where we return -EXDEV if:
>>>>
>>>> 1) we don't have ->copy_file_range *and*
>>>> 2) we have ->remap_file_range but the i_sb are different.
>>>>
>>>> The check in vfs_copy_file_range() is only executed if:
>>>>
>>>> 1) we have *valid* ->copy_file_range ops and/or
>>>> 2) we have *valid* ->remap_file_range
>>>>
>>>> So... if we remove the check in generic_copy_file_checks() as you
>>>> suggest
>>>> and:
>>>> - we don't have ->copy_file_range,
>>>> - we have ->remap_file_range but
>>>> - the i_sb are different
>>>>
>>>> we'll return the -EOPNOTSUPP (the one set in line "ret =
>>>> -EOPNOTSUPP;" in
>>>> function vfs_copy_file_range() ) instead of -EXDEV.
>>> Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
>>> -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
>>> vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
>>> the correct error code for this case? It seems to me that -EOPNOTSUPP
>>> is more appropriate than EXDEV when (sb1 != sb2).
> EXDEV is the right code for:
> filesystem supports the operation but not for sb1 != sb1.
>
>> So with the current patch, for a clone operation across 2 filesystems:
>>
>>     . if src and dst filesystem support both copy_file_range and
>>       map_file_range then the code returns -ENOTSUPPORT.
>>
> Why do you say that?
> Which code are you referring to exactly?

If the filesystems support both copy_file_range and map_file_range,
it passes the check in generic_file_check but it fails with the
check in vfs_copy_file_range and returns -ENOTSUPPORT (added by
the v8 patch)

-Dai

> Did you see this behavior in a test?
>
>>     . if the filesystems only support map_file_range then the
>>       code returns -EXDEV
>>
>> This seems confusing, shouldn't only 1 error code returned for this case?
>>
>  From my read of the code, user will get -EXDEV in both the cases you
> listed.
>
> Thanks,
> Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Olga Kornievskaia]

On Tue, Feb 23, 2021 at 11:03 AM <dai.ngo@oracle.com> wrote:
>
>
> On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
> >
> > On 2/23/21 2:32 AM, Luis Henriques wrote:
> >> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
> >>> On 2/22/21 2:24 AM, Luis Henriques wrote:
> >>>> A regression has been reported by Nicolas Boichat, found while
> >>>> using the
> >>>> copy_file_range syscall to copy a tracefs file.  Before commit
> >>>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> >>>> kernel would return -EXDEV to userspace when trying to copy a file
> >>>> across
> >>>> different filesystems.  After this commit, the syscall doesn't fail
> >>>> anymore
> >>>> and instead returns zero (zero bytes copied), as this file's
> >>>> content is
> >>>> generated on-the-fly and thus reports a size of zero.
> >>>>
> >>>> This patch restores some cross-filesystem copy restrictions that
> >>>> existed
> >>>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
> >>>> across
> >>>> devices").  Filesystems are still allowed to fall-back to the VFS
> >>>> generic_copy_file_range() implementation, but that has now to be done
> >>>> explicitly.
> >>>>
> >>>> nfsd is also modified to fall-back into generic_copy_file_range()
> >>>> in case
> >>>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> >>>>
> >>>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> >>>> devices")
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> >>>> Link:
> >>>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> >>>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> >>>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> >>>> ---
> >>>> Changes since v7
> >>>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
> >>>> that the
> >>>>     error returned is always related to the 'copy' operation
> >>>> Changes since v6
> >>>> - restored i_sb checks for the clone operation
> >>>> Changes since v5
> >>>> - check if ->copy_file_range is NULL before calling it
> >>>> Changes since v4
> >>>> - nfsd falls-back to generic_copy_file_range() only *if* it gets
> >>>> -EOPNOTSUPP
> >>>>     or -EXDEV.
> >>>> Changes since v3
> >>>> - dropped the COPY_FILE_SPLICE flag
> >>>> - kept the f_op's checks early in generic_copy_file_checks,
> >>>> implementing
> >>>>     Amir's suggestions
> >>>> - modified nfsd to use generic_copy_file_range()
> >>>> Changes since v2
> >>>> - do all the required checks earlier, in generic_copy_file_checks(),
> >>>>     adding new checks for ->remap_file_range
> >>>> - new COPY_FILE_SPLICE flag
> >>>> - don't remove filesystem's fallback to generic_copy_file_range()
> >>>> - updated commit changelog (and subject)
> >>>> Changes since v1 (after Amir review)
> >>>> - restored do_copy_file_range() helper
> >>>> - return -EOPNOTSUPP if fs doesn't implement CFR
> >>>> - updated commit description
> >>>>
> >>>>    fs/nfsd/vfs.c   |  8 +++++++-
> >>>>    fs/read_write.c | 49
> >>>> ++++++++++++++++++++++++-------------------------
> >>>>    2 files changed, 31 insertions(+), 26 deletions(-)
> >>>>
> >>>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> >>>> index 04937e51de56..23dab0fa9087 100644
> >>>> --- a/fs/nfsd/vfs.c
> >>>> +++ b/fs/nfsd/vfs.c
> >>>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
> >>>> *nf_src, u64 src_pos,
> >>>>    ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
> >>>> struct file *dst,
> >>>>                     u64 dst_pos, u64 count)
> >>>>    {
> >>>> +    ssize_t ret;
> >>>>        /*
> >>>>         * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> >>>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
> >>>> u64 src_pos, struct file *dst,
> >>>>         * limit like this and pipeline multiple COPY requests.
> >>>>         */
> >>>>        count = min_t(u64, count, 1 << 22);
> >>>> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >>>> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> >>>> +
> >>>> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
> >>>> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> >>>> +                          count, 0);
> >>>> +    return ret;
> >>>>    }
> >>>>    __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
> >>>> *fhp,
> >>>> diff --git a/fs/read_write.c b/fs/read_write.c
> >>>> index 75f764b43418..5a26297fd410 100644
> >>>> --- a/fs/read_write.c
> >>>> +++ b/fs/read_write.c
> >>>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
> >>>> *file_in, loff_t pos_in,
> >>>>    }
> >>>>    EXPORT_SYMBOL(generic_copy_file_range);
> >>>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t
> >>>> pos_in,
> >>>> -                  struct file *file_out, loff_t pos_out,
> >>>> -                  size_t len, unsigned int flags)
> >>>> -{
> >>>> -    /*
> >>>> -     * Although we now allow filesystems to handle cross sb copy,
> >>>> passing
> >>>> -     * a file of the wrong filesystem type to filesystem driver
> >>>> can result
> >>>> -     * in an attempt to dereference the wrong type of
> >>>> ->private_data, so
> >>>> -     * avoid doing that until we really have a good reason.  NFS
> >>>> defines
> >>>> -     * several different file_system_type structures, but they all
> >>>> end up
> >>>> -     * using the same ->copy_file_range() function pointer.
> >>>> -     */
> >>>> -    if (file_out->f_op->copy_file_range &&
> >>>> -        file_out->f_op->copy_file_range ==
> >>>> file_in->f_op->copy_file_range)
> >>>> -        return file_out->f_op->copy_file_range(file_in, pos_in,
> >>>> -                               file_out, pos_out,
> >>>> -                               len, flags);
> >>>> -
> >>>> -    return generic_copy_file_range(file_in, pos_in, file_out,
> >>>> pos_out, len,
> >>>> -                       flags);
> >>>> -}
> >>>> -
> >>>>    /*
> >>>>     * Performs necessary checks before doing a file copy
> >>>>     *
> >>>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
> >>>> file *file_in, loff_t pos_in,
> >>>>        loff_t size_in;
> >>>>        int ret;
> >>>> +    /*
> >>>> +     * Although we now allow filesystems to handle cross sb copy,
> >>>> passing
> >>>> +     * a file of the wrong filesystem type to filesystem driver
> >>>> can result
> >>>> +     * in an attempt to dereference the wrong type of
> >>>> ->private_data, so
> >>>> +     * avoid doing that until we really have a good reason.  NFS
> >>>> defines
> >>>> +     * several different file_system_type structures, but they all
> >>>> end up
> >>>> +     * using the same ->copy_file_range() function pointer.
> >>>> +     */
> >>>> +    if (file_out->f_op->copy_file_range) {
> >>>> +        if (file_in->f_op->copy_file_range !=
> >>>> +            file_out->f_op->copy_file_range)
> >>>> +            return -EXDEV;
> >>>> +    } else if (file_in->f_op->remap_file_range) {
> >>>> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >>>> +            return -EXDEV;
> >>> I think this check is redundant, it's done in vfs_copy_file_range.
> >>> If this check is removed then the else clause below should be removed
> >>> also. Once this check and the else clause are removed then might as
> >>> well move the the check of copy_file_range from here to
> >>> vfs_copy_file_range.
> >>>
> >> I don't think it's really redundant, although I agree is messy due to
> >> the
> >> fact we try to clone first instead of copying them.
> >>
> >> So, in the clone path, this is the only place where we return -EXDEV if:
> >>
> >> 1) we don't have ->copy_file_range *and*
> >> 2) we have ->remap_file_range but the i_sb are different.
> >>
> >> The check in vfs_copy_file_range() is only executed if:
> >>
> >> 1) we have *valid* ->copy_file_range ops and/or
> >> 2) we have *valid* ->remap_file_range
> >>
> >> So... if we remove the check in generic_copy_file_checks() as you
> >> suggest
> >> and:
> >> - we don't have ->copy_file_range,
> >> - we have ->remap_file_range but
> >> - the i_sb are different
> >>
> >> we'll return the -EOPNOTSUPP (the one set in line "ret =
> >> -EOPNOTSUPP;" in
> >> function vfs_copy_file_range() ) instead of -EXDEV.
> >
> > Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
> > -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
> > vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
> > the correct error code for this case? It seems to me that -EOPNOTSUPP
> > is more appropriate than EXDEV when (sb1 != sb2).
>
> So with the current patch, for a clone operation across 2 filesystems:

Wait, I can't get passed "a clone operation across 2 filesystems", I
thought there are not any options. It's not allowed? Then we go do try
the copy. Those are two different steps so errors code might be
different.

>    . if src and dst filesystem support both copy_file_range and
>      map_file_range then the code returns -ENOTSUPPORT.
>
>    . if the filesystems only support map_file_range then the
>      code returns -EXDEV
>
> This seems confusing, shouldn't only 1 error code returned for this case?
>
> -Dai
>
> >
> >>
> >> But I may have got it all wrong.  I've looked so many times at this code
> >> that I'm probably useless at finding problems in it :-)
> >
> > You're not alone, we all try to do the right thing :-)
> >
> > -Dai
> >
> >>
> >> Cheers,
> >> --
> >> Luís
> >>
> >>> -Dai
> >>>
> >>>> +    } else {
> >>>> +                return -EOPNOTSUPP;
> >>>> +    }
> >>>> +
> >>>>        ret = generic_file_rw_checks(file_in, file_out);
> >>>>        if (ret)
> >>>>            return ret;
> >>>> @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file
> >>>> *file_in, loff_t pos_in,
> >>>>        file_start_write(file_out);
> >>>> +    ret = -EOPNOTSUPP;
> >>>>        /*
> >>>>         * Try cloning first, this is supported by more file
> >>>> systems, and
> >>>>         * more efficient if both clone and copy are supported (e.g.
> >>>> NFS).
> >>>> @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file
> >>>> *file_in, loff_t pos_in,
> >>>>            }
> >>>>        }
> >>>> -    ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> >>>> -                flags);
> >>>> -    WARN_ON_ONCE(ret == -EOPNOTSUPP);
> >>>> +    if (file_out->f_op->copy_file_range)
> >>>> +        ret = file_out->f_op->copy_file_range(file_in, pos_in,
> >>>> +                              file_out, pos_out,
> >>>> +                              len, flags);
> >>>>    done:
> >>>>        if (ret > 0) {
> >>>>            fsnotify_access(file_in);

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Amir Goldstein]

On Tue, Feb 23, 2021 at 7:31 PM <dai.ngo@oracle.com> wrote:
>
> On 2/23/21 8:57 AM, dai.ngo@oracle.com wrote:
>
>
> On 2/23/21 8:47 AM, Amir Goldstein wrote:
>
> On Tue, Feb 23, 2021 at 6:02 PM <dai.ngo@oracle.com> wrote:
>
>
> On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
>
> On 2/23/21 2:32 AM, Luis Henriques wrote:
>
> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
>
> On 2/22/21 2:24 AM, Luis Henriques wrote:
>
> A regression has been reported by Nicolas Boichat, found while
> using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file
> across
> different filesystems.  After this commit, the syscall doesn't fail
> anymore
> and instead returns zero (zero bytes copied), as this file's
> content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that
> existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
> across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range()
> in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices")
> Link:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> Link:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> Link:
> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Changes since v7
> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
> that the
>      error returned is always related to the 'copy' operation
> Changes since v6
> - restored i_sb checks for the clone operation
> Changes since v5
> - check if ->copy_file_range is NULL before calling it
> Changes since v4
> - nfsd falls-back to generic_copy_file_range() only *if* it gets
> -EOPNOTSUPP
>      or -EXDEV.
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks,
> implementing
>      Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>      adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>     fs/nfsd/vfs.c   |  8 +++++++-
>     fs/read_write.c | 49
> ++++++++++++++++++++++++-------------------------
>     2 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..23dab0fa9087 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
> *nf_src, u64 src_pos,
>     ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
> struct file *dst,
>                      u64 dst_pos, u64 count)
>     {
> +    ssize_t ret;
>         /*
>          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
> u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +
> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> +                          count, 0);
> +    return ret;
>     }
>     __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
> *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..5a26297fd410 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
> *file_in, loff_t pos_in,
>     }
>     EXPORT_SYMBOL(generic_copy_file_range);
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t
> pos_in,
> -                  struct file *file_out, loff_t pos_out,
> -                  size_t len, unsigned int flags)
> -{
> -    /*
> -     * Although we now allow filesystems to handle cross sb copy,
> passing
> -     * a file of the wrong filesystem type to filesystem driver
> can result
> -     * in an attempt to dereference the wrong type of
> ->private_data, so
> -     * avoid doing that until we really have a good reason.  NFS
> defines
> -     * several different file_system_type structures, but they all
> end up
> -     * using the same ->copy_file_range() function pointer.
> -     */
> -    if (file_out->f_op->copy_file_range &&
> -        file_out->f_op->copy_file_range ==
> file_in->f_op->copy_file_range)
> -        return file_out->f_op->copy_file_range(file_in, pos_in,
> -                               file_out, pos_out,
> -                               len, flags);
> -
> -    return generic_copy_file_range(file_in, pos_in, file_out,
> pos_out, len,
> -                       flags);
> -}
> -
>     /*
>      * Performs necessary checks before doing a file copy
>      *
> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
> file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
> +    /*
> +     * Although we now allow filesystems to handle cross sb copy,
> passing
> +     * a file of the wrong filesystem type to filesystem driver
> can result
> +     * in an attempt to dereference the wrong type of
> ->private_data, so
> +     * avoid doing that until we really have a good reason.  NFS
> defines
> +     * several different file_system_type structures, but they all
> end up
> +     * using the same ->copy_file_range() function pointer.
> +     */
> +    if (file_out->f_op->copy_file_range) {
> +        if (file_in->f_op->copy_file_range !=
> +            file_out->f_op->copy_file_range)
> +            return -EXDEV;
> +    } else if (file_in->f_op->remap_file_range) {
> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +            return -EXDEV;
>
> I think this check is redundant, it's done in vfs_copy_file_range.
> If this check is removed then the else clause below should be removed
> also. Once this check and the else clause are removed then might as
> well move the the check of copy_file_range from here to
> vfs_copy_file_range.
>
> I don't think it's really redundant, although I agree is messy due to
> the
> fact we try to clone first instead of copying them.
>
> So, in the clone path, this is the only place where we return -EXDEV if:
>
> 1) we don't have ->copy_file_range *and*
> 2) we have ->remap_file_range but the i_sb are different.
>
> The check in vfs_copy_file_range() is only executed if:
>
> 1) we have *valid* ->copy_file_range ops and/or
> 2) we have *valid* ->remap_file_range
>
> So... if we remove the check in generic_copy_file_checks() as you
> suggest
> and:
> - we don't have ->copy_file_range,
> - we have ->remap_file_range but
> - the i_sb are different
>
> we'll return the -EOPNOTSUPP (the one set in line "ret =
> -EOPNOTSUPP;" in
> function vfs_copy_file_range() ) instead of -EXDEV.
>
> Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
> -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
> vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
> the correct error code for this case? It seems to me that -EOPNOTSUPP
> is more appropriate than EXDEV when (sb1 != sb2).
>
> EXDEV is the right code for:
> filesystem supports the operation but not for sb1 != sb1.
>
> So with the current patch, for a clone operation across 2 filesystems:
>
>     . if src and dst filesystem support both copy_file_range and
>       map_file_range then the code returns -ENOTSUPPORT.
>
> Why do you say that?
> Which code are you referring to exactly?
>
>
> If the filesystems support both copy_file_range and map_file_range,
> it passes the check in generic_file_check but it fails with the
> check in vfs_copy_file_range and returns -ENOTSUPPORT (added by
> the v8 patch)
>
> Ok, I misread the code here. If it passes the check in generic_copy_file_checks
> and it fails the sb check in vfs_copy_file_range then it tries copy_file_range
> so it's ok.
>
> I think having the check in both generic_copy_file_checks and vfs_copy_file_range
> making the code hard to read. What's the reason not to do the check only in
> vfs_copy_file_range?
>

You are going in circles.
I already answered that.
Please re-read the entire thread on all patch versions before commenting.

Thanks,
Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Luis Henriques]

On Tue, Feb 23, 2021 at 08:57:38AM -0800, dai.ngo@oracle.com wrote:
> 
> On 2/23/21 8:47 AM, Amir Goldstein wrote:
> > On Tue, Feb 23, 2021 at 6:02 PM <dai.ngo@oracle.com> wrote:
> > > 
> > > On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
> > > > On 2/23/21 2:32 AM, Luis Henriques wrote:
> > > > > On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
> > > > > > On 2/22/21 2:24 AM, Luis Henriques wrote:
> > > > > > > A regression has been reported by Nicolas Boichat, found while
> > > > > > > using the
> > > > > > > copy_file_range syscall to copy a tracefs file.  Before commit
> > > > > > > 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> > > > > > > kernel would return -EXDEV to userspace when trying to copy a file
> > > > > > > across
> > > > > > > different filesystems.  After this commit, the syscall doesn't fail
> > > > > > > anymore
> > > > > > > and instead returns zero (zero bytes copied), as this file's
> > > > > > > content is
> > > > > > > generated on-the-fly and thus reports a size of zero.
> > > > > > > 
> > > > > > > This patch restores some cross-filesystem copy restrictions that
> > > > > > > existed
> > > > > > > prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
> > > > > > > across
> > > > > > > devices").  Filesystems are still allowed to fall-back to the VFS
> > > > > > > generic_copy_file_range() implementation, but that has now to be done
> > > > > > > explicitly.
> > > > > > > 
> > > > > > > nfsd is also modified to fall-back into generic_copy_file_range()
> > > > > > > in case
> > > > > > > vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
> > > > > > > 
> > > > > > > Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> > > > > > > devices")
> > > > > > > Link:
> > > > > > > https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
> > > > > > > Link:
> > > > > > > https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
> > > > > > > Link:
> > > > > > > https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
> > > > > > > Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> > > > > > > Signed-off-by: Luis Henriques <lhenriques@suse.de>
> > > > > > > ---
> > > > > > > Changes since v7
> > > > > > > - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
> > > > > > > that the
> > > > > > >      error returned is always related to the 'copy' operation
> > > > > > > Changes since v6
> > > > > > > - restored i_sb checks for the clone operation
> > > > > > > Changes since v5
> > > > > > > - check if ->copy_file_range is NULL before calling it
> > > > > > > Changes since v4
> > > > > > > - nfsd falls-back to generic_copy_file_range() only *if* it gets
> > > > > > > -EOPNOTSUPP
> > > > > > >      or -EXDEV.
> > > > > > > Changes since v3
> > > > > > > - dropped the COPY_FILE_SPLICE flag
> > > > > > > - kept the f_op's checks early in generic_copy_file_checks,
> > > > > > > implementing
> > > > > > >      Amir's suggestions
> > > > > > > - modified nfsd to use generic_copy_file_range()
> > > > > > > Changes since v2
> > > > > > > - do all the required checks earlier, in generic_copy_file_checks(),
> > > > > > >      adding new checks for ->remap_file_range
> > > > > > > - new COPY_FILE_SPLICE flag
> > > > > > > - don't remove filesystem's fallback to generic_copy_file_range()
> > > > > > > - updated commit changelog (and subject)
> > > > > > > Changes since v1 (after Amir review)
> > > > > > > - restored do_copy_file_range() helper
> > > > > > > - return -EOPNOTSUPP if fs doesn't implement CFR
> > > > > > > - updated commit description
> > > > > > > 
> > > > > > >     fs/nfsd/vfs.c   |  8 +++++++-
> > > > > > >     fs/read_write.c | 49
> > > > > > > ++++++++++++++++++++++++-------------------------
> > > > > > >     2 files changed, 31 insertions(+), 26 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> > > > > > > index 04937e51de56..23dab0fa9087 100644
> > > > > > > --- a/fs/nfsd/vfs.c
> > > > > > > +++ b/fs/nfsd/vfs.c
> > > > > > > @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
> > > > > > > *nf_src, u64 src_pos,
> > > > > > >     ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
> > > > > > > struct file *dst,
> > > > > > >                      u64 dst_pos, u64 count)
> > > > > > >     {
> > > > > > > +    ssize_t ret;
> > > > > > >         /*
> > > > > > >          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> > > > > > > @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
> > > > > > > u64 src_pos, struct file *dst,
> > > > > > >          * limit like this and pipeline multiple COPY requests.
> > > > > > >          */
> > > > > > >         count = min_t(u64, count, 1 << 22);
> > > > > > > -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > > > > > > +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> > > > > > > +
> > > > > > > +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
> > > > > > > +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> > > > > > > +                          count, 0);
> > > > > > > +    return ret;
> > > > > > >     }
> > > > > > >     __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
> > > > > > > *fhp,
> > > > > > > diff --git a/fs/read_write.c b/fs/read_write.c
> > > > > > > index 75f764b43418..5a26297fd410 100644
> > > > > > > --- a/fs/read_write.c
> > > > > > > +++ b/fs/read_write.c
> > > > > > > @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
> > > > > > > *file_in, loff_t pos_in,
> > > > > > >     }
> > > > > > >     EXPORT_SYMBOL(generic_copy_file_range);
> > > > > > > -static ssize_t do_copy_file_range(struct file *file_in, loff_t
> > > > > > > pos_in,
> > > > > > > -                  struct file *file_out, loff_t pos_out,
> > > > > > > -                  size_t len, unsigned int flags)
> > > > > > > -{
> > > > > > > -    /*
> > > > > > > -     * Although we now allow filesystems to handle cross sb copy,
> > > > > > > passing
> > > > > > > -     * a file of the wrong filesystem type to filesystem driver
> > > > > > > can result
> > > > > > > -     * in an attempt to dereference the wrong type of
> > > > > > > ->private_data, so
> > > > > > > -     * avoid doing that until we really have a good reason.  NFS
> > > > > > > defines
> > > > > > > -     * several different file_system_type structures, but they all
> > > > > > > end up
> > > > > > > -     * using the same ->copy_file_range() function pointer.
> > > > > > > -     */
> > > > > > > -    if (file_out->f_op->copy_file_range &&
> > > > > > > -        file_out->f_op->copy_file_range ==
> > > > > > > file_in->f_op->copy_file_range)
> > > > > > > -        return file_out->f_op->copy_file_range(file_in, pos_in,
> > > > > > > -                               file_out, pos_out,
> > > > > > > -                               len, flags);
> > > > > > > -
> > > > > > > -    return generic_copy_file_range(file_in, pos_in, file_out,
> > > > > > > pos_out, len,
> > > > > > > -                       flags);
> > > > > > > -}
> > > > > > > -
> > > > > > >     /*
> > > > > > >      * Performs necessary checks before doing a file copy
> > > > > > >      *
> > > > > > > @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
> > > > > > > file *file_in, loff_t pos_in,
> > > > > > >         loff_t size_in;
> > > > > > >         int ret;
> > > > > > > +    /*
> > > > > > > +     * Although we now allow filesystems to handle cross sb copy,
> > > > > > > passing
> > > > > > > +     * a file of the wrong filesystem type to filesystem driver
> > > > > > > can result
> > > > > > > +     * in an attempt to dereference the wrong type of
> > > > > > > ->private_data, so
> > > > > > > +     * avoid doing that until we really have a good reason.  NFS
> > > > > > > defines
> > > > > > > +     * several different file_system_type structures, but they all
> > > > > > > end up
> > > > > > > +     * using the same ->copy_file_range() function pointer.
> > > > > > > +     */
> > > > > > > +    if (file_out->f_op->copy_file_range) {
> > > > > > > +        if (file_in->f_op->copy_file_range !=
> > > > > > > +            file_out->f_op->copy_file_range)
> > > > > > > +            return -EXDEV;
> > > > > > > +    } else if (file_in->f_op->remap_file_range) {
> > > > > > > +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> > > > > > > +            return -EXDEV;
> > > > > > I think this check is redundant, it's done in vfs_copy_file_range.
> > > > > > If this check is removed then the else clause below should be removed
> > > > > > also. Once this check and the else clause are removed then might as
> > > > > > well move the the check of copy_file_range from here to
> > > > > > vfs_copy_file_range.
> > > > > > 
> > > > > I don't think it's really redundant, although I agree is messy due to
> > > > > the
> > > > > fact we try to clone first instead of copying them.
> > > > > 
> > > > > So, in the clone path, this is the only place where we return -EXDEV if:
> > > > > 
> > > > > 1) we don't have ->copy_file_range *and*
> > > > > 2) we have ->remap_file_range but the i_sb are different.
> > > > > 
> > > > > The check in vfs_copy_file_range() is only executed if:
> > > > > 
> > > > > 1) we have *valid* ->copy_file_range ops and/or
> > > > > 2) we have *valid* ->remap_file_range
> > > > > 
> > > > > So... if we remove the check in generic_copy_file_checks() as you
> > > > > suggest
> > > > > and:
> > > > > - we don't have ->copy_file_range,
> > > > > - we have ->remap_file_range but
> > > > > - the i_sb are different
> > > > > 
> > > > > we'll return the -EOPNOTSUPP (the one set in line "ret =
> > > > > -EOPNOTSUPP;" in
> > > > > function vfs_copy_file_range() ) instead of -EXDEV.
> > > > Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
> > > > -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
> > > > vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
> > > > the correct error code for this case? It seems to me that -EOPNOTSUPP
> > > > is more appropriate than EXDEV when (sb1 != sb2).
> > EXDEV is the right code for:
> > filesystem supports the operation but not for sb1 != sb1.
> > 
> > > So with the current patch, for a clone operation across 2 filesystems:
> > > 
> > >     . if src and dst filesystem support both copy_file_range and
> > >       map_file_range then the code returns -ENOTSUPPORT.
> > > 
> > Why do you say that?
> > Which code are you referring to exactly?
> 
> If the filesystems support both copy_file_range and map_file_range,
> it passes the check in generic_file_check but it fails with the
> check in vfs_copy_file_range and returns -ENOTSUPPORT (added by
> the v8 patch)

I'm sorry but I can't simply see where this can happen.  If both syscalls
are present (and all other checks pass), the code will first try the
->map_file_range.  If that succeeds, it bails out; if that fails, it tries
the ->copy_file_range.  The -ENOTSUPPORT is just there for the case the
->map_file_range fails and ->copy_file_range isn't implemented.

[ <sigh> It would be so much easier if we didn't attempt to clone. ]

But as I said previously, I'm way beyond embarrassment now as I failed to
see too many obvious mistakes in previous versions :-)

Cheers,
--
Luís

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[dai.ngo]

On 2/23/21 9:33 AM, Amir Goldstein wrote:
> On Tue, Feb 23, 2021 at 7:31 PM <dai.ngo@oracle.com> wrote:
>> On 2/23/21 8:57 AM, dai.ngo@oracle.com wrote:
>>
>>
>> On 2/23/21 8:47 AM, Amir Goldstein wrote:
>>
>> On Tue, Feb 23, 2021 at 6:02 PM <dai.ngo@oracle.com> wrote:
>>
>>
>> On 2/23/21 7:29 AM, dai.ngo@oracle.com wrote:
>>
>> On 2/23/21 2:32 AM, Luis Henriques wrote:
>>
>> On Mon, Feb 22, 2021 at 08:25:27AM -0800, dai.ngo@oracle.com wrote:
>>
>> On 2/22/21 2:24 AM, Luis Henriques wrote:
>>
>> A regression has been reported by Nicolas Boichat, found while
>> using the
>> copy_file_range syscall to copy a tracefs file.  Before commit
>> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
>> kernel would return -EXDEV to userspace when trying to copy a file
>> across
>> different filesystems.  After this commit, the syscall doesn't fail
>> anymore
>> and instead returns zero (zero bytes copied), as this file's
>> content is
>> generated on-the-fly and thus reports a size of zero.
>>
>> This patch restores some cross-filesystem copy restrictions that
>> existed
>> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy
>> across
>> devices").  Filesystems are still allowed to fall-back to the VFS
>> generic_copy_file_range() implementation, but that has now to be done
>> explicitly.
>>
>> nfsd is also modified to fall-back into generic_copy_file_range()
>> in case
>> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>>
>> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
>> devices")
>> Link:
>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmi49dC6w$
>> Link:
>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx*BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/__;Kw!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmgCmMHzA$
>> Link:
>> https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/__;!!GqivPVa7Brio!P1UWThiSkxbjfjFQWNYJmCxGEkiLFyvHjH6cS-G1ZTt1z-TeqwGQgQmzqItkrQ$
>> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
>> Signed-off-by: Luis Henriques <lhenriques@suse.de>
>> ---
>> Changes since v7
>> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so
>> that the
>>       error returned is always related to the 'copy' operation
>> Changes since v6
>> - restored i_sb checks for the clone operation
>> Changes since v5
>> - check if ->copy_file_range is NULL before calling it
>> Changes since v4
>> - nfsd falls-back to generic_copy_file_range() only *if* it gets
>> -EOPNOTSUPP
>>       or -EXDEV.
>> Changes since v3
>> - dropped the COPY_FILE_SPLICE flag
>> - kept the f_op's checks early in generic_copy_file_checks,
>> implementing
>>       Amir's suggestions
>> - modified nfsd to use generic_copy_file_range()
>> Changes since v2
>> - do all the required checks earlier, in generic_copy_file_checks(),
>>       adding new checks for ->remap_file_range
>> - new COPY_FILE_SPLICE flag
>> - don't remove filesystem's fallback to generic_copy_file_range()
>> - updated commit changelog (and subject)
>> Changes since v1 (after Amir review)
>> - restored do_copy_file_range() helper
>> - return -EOPNOTSUPP if fs doesn't implement CFR
>> - updated commit description
>>
>>      fs/nfsd/vfs.c   |  8 +++++++-
>>      fs/read_write.c | 49
>> ++++++++++++++++++++++++-------------------------
>>      2 files changed, 31 insertions(+), 26 deletions(-)
>>
>> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
>> index 04937e51de56..23dab0fa9087 100644
>> --- a/fs/nfsd/vfs.c
>> +++ b/fs/nfsd/vfs.c
>> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file
>> *nf_src, u64 src_pos,
>>      ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos,
>> struct file *dst,
>>                       u64 dst_pos, u64 count)
>>      {
>> +    ssize_t ret;
>>          /*
>>           * Limit copy to 4MB to prevent indefinitely blocking an nfsd
>> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src,
>> u64 src_pos, struct file *dst,
>>           * limit like this and pipeline multiple COPY requests.
>>           */
>>          count = min_t(u64, count, 1 << 22);
>> -    return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>> +    ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
>> +
>> +    if (ret == -EOPNOTSUPP || ret == -EXDEV)
>> +        ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
>> +                          count, 0);
>> +    return ret;
>>      }
>>      __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh
>> *fhp,
>> diff --git a/fs/read_write.c b/fs/read_write.c
>> index 75f764b43418..5a26297fd410 100644
>> --- a/fs/read_write.c
>> +++ b/fs/read_write.c
>> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file
>> *file_in, loff_t pos_in,
>>      }
>>      EXPORT_SYMBOL(generic_copy_file_range);
>> -static ssize_t do_copy_file_range(struct file *file_in, loff_t
>> pos_in,
>> -                  struct file *file_out, loff_t pos_out,
>> -                  size_t len, unsigned int flags)
>> -{
>> -    /*
>> -     * Although we now allow filesystems to handle cross sb copy,
>> passing
>> -     * a file of the wrong filesystem type to filesystem driver
>> can result
>> -     * in an attempt to dereference the wrong type of
>> ->private_data, so
>> -     * avoid doing that until we really have a good reason.  NFS
>> defines
>> -     * several different file_system_type structures, but they all
>> end up
>> -     * using the same ->copy_file_range() function pointer.
>> -     */
>> -    if (file_out->f_op->copy_file_range &&
>> -        file_out->f_op->copy_file_range ==
>> file_in->f_op->copy_file_range)
>> -        return file_out->f_op->copy_file_range(file_in, pos_in,
>> -                               file_out, pos_out,
>> -                               len, flags);
>> -
>> -    return generic_copy_file_range(file_in, pos_in, file_out,
>> pos_out, len,
>> -                       flags);
>> -}
>> -
>>      /*
>>       * Performs necessary checks before doing a file copy
>>       *
>> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct
>> file *file_in, loff_t pos_in,
>>          loff_t size_in;
>>          int ret;
>> +    /*
>> +     * Although we now allow filesystems to handle cross sb copy,
>> passing
>> +     * a file of the wrong filesystem type to filesystem driver
>> can result
>> +     * in an attempt to dereference the wrong type of
>> ->private_data, so
>> +     * avoid doing that until we really have a good reason.  NFS
>> defines
>> +     * several different file_system_type structures, but they all
>> end up
>> +     * using the same ->copy_file_range() function pointer.
>> +     */
>> +    if (file_out->f_op->copy_file_range) {
>> +        if (file_in->f_op->copy_file_range !=
>> +            file_out->f_op->copy_file_range)
>> +            return -EXDEV;
>> +    } else if (file_in->f_op->remap_file_range) {
>> +        if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>> +            return -EXDEV;
>>
>> I think this check is redundant, it's done in vfs_copy_file_range.
>> If this check is removed then the else clause below should be removed
>> also. Once this check and the else clause are removed then might as
>> well move the the check of copy_file_range from here to
>> vfs_copy_file_range.
>>
>> I don't think it's really redundant, although I agree is messy due to
>> the
>> fact we try to clone first instead of copying them.
>>
>> So, in the clone path, this is the only place where we return -EXDEV if:
>>
>> 1) we don't have ->copy_file_range *and*
>> 2) we have ->remap_file_range but the i_sb are different.
>>
>> The check in vfs_copy_file_range() is only executed if:
>>
>> 1) we have *valid* ->copy_file_range ops and/or
>> 2) we have *valid* ->remap_file_range
>>
>> So... if we remove the check in generic_copy_file_checks() as you
>> suggest
>> and:
>> - we don't have ->copy_file_range,
>> - we have ->remap_file_range but
>> - the i_sb are different
>>
>> we'll return the -EOPNOTSUPP (the one set in line "ret =
>> -EOPNOTSUPP;" in
>> function vfs_copy_file_range() ) instead of -EXDEV.
>>
>> Yes, this is the different.The NFS code handles both -EOPNOTSUPP and
>> -EXDEVV by doing generic_copy_file_range.  Do any other consumers of
>> vfs_copy_file_range rely on -EXDEV and not -EOPNOTSUPP and which is
>> the correct error code for this case? It seems to me that -EOPNOTSUPP
>> is more appropriate than EXDEV when (sb1 != sb2).
>>
>> EXDEV is the right code for:
>> filesystem supports the operation but not for sb1 != sb1.
>>
>> So with the current patch, for a clone operation across 2 filesystems:
>>
>>      . if src and dst filesystem support both copy_file_range and
>>        map_file_range then the code returns -ENOTSUPPORT.
>>
>> Why do you say that?
>> Which code are you referring to exactly?
>>
>>
>> If the filesystems support both copy_file_range and map_file_range,
>> it passes the check in generic_file_check but it fails with the
>> check in vfs_copy_file_range and returns -ENOTSUPPORT (added by
>> the v8 patch)
>>
>> Ok, I misread the code here. If it passes the check in generic_copy_file_checks
>> and it fails the sb check in vfs_copy_file_range then it tries copy_file_range
>> so it's ok.
>>
>> I think having the check in both generic_copy_file_checks and vfs_copy_file_range
>> making the code hard to read. What's the reason not to do the check only in
>> vfs_copy_file_range?
>>
> You are going in circles.
> I already answered that.
> Please re-read the entire thread on all patch versions before commenting.

I'm fine with the patch as it is, as long as it does not break NFS.

I just think it's easier to read if the checks are done in
vfs_copy_file_range such as:

@@ -1495,6 +1473,11 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
  
         file_start_write(file_out);
  
+       if (file_out->f_op->copy_file_range == NULL &&
+           file_in->f_op->remap_file_range == NULL)
+               return -EOPNOTSUPP;     /* not sure this error is needed */
+
+       ret = -EXDEV;
         /*
          * Try cloning first, this is supported by more file systems, and
          * more efficient if both clone and copy are supported (e.g. NFS).
@@ -1513,9 +1496,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
                 }
         }
  
-       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
-                               flags);
-       WARN_ON_ONCE(ret == -EOPNOTSUPP);
+       if (file_out->f_op->copy_file_range &&
+           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range) {
+               ret = file_out->f_op->copy_file_range(file_in, pos_in,
+                               file_out, pos_out, len, flags);
  done:
         if (ret > 0) {
                 fsnotify_access(file_in);

Thanks,
-Dai

>
> Thanks,
> Amir.

Re: [PATCH v8] vfs: fix copy_file_range regression in cross-fs copies

[Olga Kornievskaia]

On Mon, Feb 22, 2021 at 5:25 AM Luis Henriques <lhenriques@suse.de> wrote:
>
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file.  Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return -EXDEV to userspace when trying to copy a file across
> different filesystems.  After this commit, the syscall doesn't fail anymore
> and instead returns zero (zero bytes copied), as this file's content is
> generated on-the-fly and thus reports a size of zero.
>
> This patch restores some cross-filesystem copy restrictions that existed
> prior to commit 5dae222a5ff0 ("vfs: allow copy_file_range to copy across
> devices").  Filesystems are still allowed to fall-back to the VFS
> generic_copy_file_range() implementation, but that has now to be done
> explicitly.
>
> nfsd is also modified to fall-back into generic_copy_file_range() in case
> vfs_copy_file_range() fails with -EOPNOTSUPP or -EXDEV.
>
> Fixes: 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices")
> Link: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@chromium.org/
> Link: https://lore.kernel.org/linux-fsdevel/CANMq1KDZuxir2LM5jOTm0xx+BnvW=ZmpsG47CyHFJwnw7zSX6Q@mail.gmail.com/
> Link: https://lore.kernel.org/linux-fsdevel/20210126135012.1.If45b7cdc3ff707bc1efa17f5366057d60603c45f@changeid/
> Reported-by: Nicolas Boichat <drinkcat@chromium.org>
> Signed-off-by: Luis Henriques <lhenriques@suse.de>

I tested v8 and I believe it works for NFS.

> ---
> Changes since v7
> - set 'ret' to '-EOPNOTSUPP' before the clone 'if' statement so that the
>   error returned is always related to the 'copy' operation
> Changes since v6
> - restored i_sb checks for the clone operation
> Changes since v5
> - check if ->copy_file_range is NULL before calling it
> Changes since v4
> - nfsd falls-back to generic_copy_file_range() only *if* it gets -EOPNOTSUPP
>   or -EXDEV.
> Changes since v3
> - dropped the COPY_FILE_SPLICE flag
> - kept the f_op's checks early in generic_copy_file_checks, implementing
>   Amir's suggestions
> - modified nfsd to use generic_copy_file_range()
> Changes since v2
> - do all the required checks earlier, in generic_copy_file_checks(),
>   adding new checks for ->remap_file_range
> - new COPY_FILE_SPLICE flag
> - don't remove filesystem's fallback to generic_copy_file_range()
> - updated commit changelog (and subject)
> Changes since v1 (after Amir review)
> - restored do_copy_file_range() helper
> - return -EOPNOTSUPP if fs doesn't implement CFR
> - updated commit description
>
>  fs/nfsd/vfs.c   |  8 +++++++-
>  fs/read_write.c | 49 ++++++++++++++++++++++++-------------------------
>  2 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index 04937e51de56..23dab0fa9087 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -568,6 +568,7 @@ __be32 nfsd4_clone_file_range(struct nfsd_file *nf_src, u64 src_pos,
>  ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>                              u64 dst_pos, u64 count)
>  {
> +       ssize_t ret;
>
>         /*
>          * Limit copy to 4MB to prevent indefinitely blocking an nfsd
> @@ -578,7 +579,12 @@ ssize_t nfsd_copy_file_range(struct file *src, u64 src_pos, struct file *dst,
>          * limit like this and pipeline multiple COPY requests.
>          */
>         count = min_t(u64, count, 1 << 22);
> -       return vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +       ret = vfs_copy_file_range(src, src_pos, dst, dst_pos, count, 0);
> +
> +       if (ret == -EOPNOTSUPP || ret == -EXDEV)
> +               ret = generic_copy_file_range(src, src_pos, dst, dst_pos,
> +                                             count, 0);
> +       return ret;
>  }
>
>  __be32 nfsd4_vfs_fallocate(struct svc_rqst *rqstp, struct svc_fh *fhp,
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..5a26297fd410 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1388,28 +1388,6 @@ ssize_t generic_copy_file_range(struct file *file_in, loff_t pos_in,
>  }
>  EXPORT_SYMBOL(generic_copy_file_range);
>
> -static ssize_t do_copy_file_range(struct file *file_in, loff_t pos_in,
> -                                 struct file *file_out, loff_t pos_out,
> -                                 size_t len, unsigned int flags)
> -{
> -       /*
> -        * Although we now allow filesystems to handle cross sb copy, passing
> -        * a file of the wrong filesystem type to filesystem driver can result
> -        * in an attempt to dereference the wrong type of ->private_data, so
> -        * avoid doing that until we really have a good reason.  NFS defines
> -        * several different file_system_type structures, but they all end up
> -        * using the same ->copy_file_range() function pointer.
> -        */
> -       if (file_out->f_op->copy_file_range &&
> -           file_out->f_op->copy_file_range == file_in->f_op->copy_file_range)
> -               return file_out->f_op->copy_file_range(file_in, pos_in,
> -                                                      file_out, pos_out,
> -                                                      len, flags);
> -
> -       return generic_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                                      flags);
> -}
> -
>  /*
>   * Performs necessary checks before doing a file copy
>   *
> @@ -1427,6 +1405,25 @@ static int generic_copy_file_checks(struct file *file_in, loff_t pos_in,
>         loff_t size_in;
>         int ret;
>
> +       /*
> +        * Although we now allow filesystems to handle cross sb copy, passing
> +        * a file of the wrong filesystem type to filesystem driver can result
> +        * in an attempt to dereference the wrong type of ->private_data, so
> +        * avoid doing that until we really have a good reason.  NFS defines
> +        * several different file_system_type structures, but they all end up
> +        * using the same ->copy_file_range() function pointer.
> +        */
> +       if (file_out->f_op->copy_file_range) {
> +               if (file_in->f_op->copy_file_range !=
> +                   file_out->f_op->copy_file_range)
> +                       return -EXDEV;
> +       } else if (file_in->f_op->remap_file_range) {
> +               if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> +                       return -EXDEV;
> +       } else {
> +                return -EOPNOTSUPP;
> +       }
> +
>         ret = generic_file_rw_checks(file_in, file_out);
>         if (ret)
>                 return ret;
> @@ -1495,6 +1492,7 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>
>         file_start_write(file_out);
>
> +       ret = -EOPNOTSUPP;
>         /*
>          * Try cloning first, this is supported by more file systems, and
>          * more efficient if both clone and copy are supported (e.g. NFS).
> @@ -1513,9 +1511,10 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
>                 }
>         }
>
> -       ret = do_copy_file_range(file_in, pos_in, file_out, pos_out, len,
> -                               flags);
> -       WARN_ON_ONCE(ret == -EOPNOTSUPP);
> +       if (file_out->f_op->copy_file_range)
> +               ret = file_out->f_op->copy_file_range(file_in, pos_in,
> +                                                     file_out, pos_out,
> +                                                     len, flags);
>  done:
>         if (ret > 0) {
>                 fsnotify_access(file_in);

[vfs] cb07c976be: ltp.copy_file_range01.fail

[kernel test robot]

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


Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: cb07c976be47c7a2633c82cda0ff75da371882b1 ("[PATCH v8] 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/20210222-182743
base: https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git overlayfs-next

in testcase: ltp
version: ltp-x86_64-14c1f76-1_20210101
with following parameters:

	disk: 1HDD
	fs: f2fs
	test: syscalls-03
	ucode: 0xe2

test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/


on test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz with 32G 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-02-23 22:42:14 ln -sf /usr/bin/genisoimage /usr/bin/mkisofs
2021-02-23 22:42:14 ./runltp -f syscalls-03 -d /fs/sda1/tmpdir
INFO: creating /lkp/benchmarks/ltp/output directory
INFO: creating /lkp/benchmarks/ltp/results directory
Checking for required user/group ids

'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

/etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

uname:
Linux lkp-skl-d02 5.11.0-rc4-00009-gcb07c976be47 #1 SMP Tue Feb 23 16:45:18 CST 2021 x86_64 GNU/Linux

/proc/cmdline
ip=::::lkp-skl-d02::dhcp root=/dev/ram0 user=lkp job=/lkp/jobs/scheduled/lkp-skl-d02/ltp-1HDD-f2fs-syscalls-03-ucode=0xe2-debian-10.4-x86_64-20200603.cgz-cb07c976be47c7a2633c82cda0ff75da371882b1-20210224-49337-15u8vpp-4.yaml ARCH=x86_64 kconfig=x86_64-rhel-8.3 branch=linux-review/Luis-Henriques/vfs-fix-copy_file_range-regression-in-cross-fs-copies/20210222-182743 commit=cb07c976be47c7a2633c82cda0ff75da371882b1 BOOT_IMAGE=/pkg/linux/x86_64-rhel-8.3/gcc-9/cb07c976be47c7a2633c82cda0ff75da371882b1/vmlinuz-5.11.0-rc4-00009-gcb07c976be47 max_uptime=2100 RESULT_ROOT=/result/ltp/1HDD-f2fs-syscalls-03-ucode=0xe2/lkp-skl-d02/debian-10.4-x86_64-20200603.cgz/x86_64-rhel-8.3/gcc-9/cb07c976be47c7a2633c82cda0ff75da371882b1/3 LKP_SERVER=internal-lkp-server nokaslr selinux=0 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw

Gnu C                  gcc (Debian 8.3.0-6) 8.3.0
Clang                 
Gnu make               4.2.1
util-linux             2.33.1
mount                  linux 2.33.1 (libmount 2.33.1: selinux, smack, btrfs, namespaces, assert, debug)
modutils               26
e2fsprogs              1.44.5
Linux C Library        > libc.2.28
Dynamic linker (ldd)   2.28
Procps                 3.3.15
Net-tools              2.10-alpha
iproute2               iproute2-ss190107
iputils                iputils-s20180629
ethtool                4.19
Kbd                    119:
Sh-utils               8.30
Modules Loaded         dm_mod f2fs xfs libcrc32c ipmi_devintf ipmi_msghandler sd_mod t10_pi sg intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel i915 kvm irqbypass intel_gtt dell_wmi crct10dif_pclmul dell_smbios drm_kms_helper crc32_pclmul crc32c_intel ahci syscopyarea sysfillrect mei_wdt libahci ghash_clmulni_intel dell_wmi_descriptor wmi_bmof sparse_keymap dcdbas sysimgblt rapl fb_sys_fops intel_cstate mei_me drm libata mei intel_uncore intel_pch_thermal wmi video intel_pmc_core acpi_pad ip_tables

free reports:
              total        used        free      shared  buff/cache   available
Mem:       32756572      342104    29911628       21800     2502840    29683164
Swap:             0           0           0

cpuinfo:
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       39 bits physical, 48 bits virtual
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               94
Model name:          Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Stepping:            3
CPU MHz:             3494.874
CPU max MHz:         3600.0000
CPU min MHz:         800.0000
BogoMIPS:            6399.96
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            6144K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

AppArmor enabled

SELinux mode: unknown
no big block device was specified on commandline.
Tests which require a big block device are disabled.
You can specify it with option -z
COMMAND:    /lkp/benchmarks/ltp/bin/ltp-pan   -e -S   -a 2528     -n 2528 -p -f /fs/sda1/tmpdir/ltp-UHIgqnJkTG/alltests -l /lkp/benchmarks/ltp/results/LTP_RUN_ON-2021_02_23-22h_42m_14s.log  -C /lkp/benchmarks/ltp/output/LTP_RUN_ON-2021_02_23-22h_42m_14s.failed -T /lkp/benchmarks/ltp/output/LTP_RUN_ON-2021_02_23-22h_42m_14s.tconf
LOG File: /lkp/benchmarks/ltp/results/LTP_RUN_ON-2021_02_23-22h_42m_14s.log
FAILED COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2021_02_23-22h_42m_14s.failed
TCONF COMMAND File: /lkp/benchmarks/ltp/output/LTP_RUN_ON-2021_02_23-22h_42m_14s.tconf
Running tests.......
<<<test_start>>>
tag=add_key01 stime=1614120134
cmdline="add_key01"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
add_key01.c:63: TINFO: The key type is keyrings and plen is 0
add_key01.c:79: TPASS: add_key call succeeded as expected
add_key01.c:63: TINFO: the key type is keyrings and plen is 1
add_key01.c:83: TPASS: add_key call failed as expected: EINVAL (22)
add_key01.c:63: TINFO: The key type is user and plen is 32767
add_key01.c:79: TPASS: add_key call succeeded as expected
add_key01.c:63: TINFO: The key type is user and plen is 32768
add_key01.c:83: TPASS: add_key call failed as expected: EINVAL (22)
add_key01.c:63: TINFO: The key type is logon and plen is 32767
add_key01.c:79: TPASS: add_key call succeeded as expected
add_key01.c:63: TINFO: The key type is logon and plen is 32768
add_key01.c:83: TPASS: add_key call failed as expected: EINVAL (22)
add_key01.c:63: TINFO: The key type is big_key and plen is 1048575
add_key01.c:70: TCONF: skipping unsupported big_key key
add_key01.c:63: TINFO: The key type is big_key and plen is 1048576
add_key01.c:70: TCONF: skipping unsupported big_key key

Summary:
passed   6
failed   0
broken   0
skipped  2
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=alarm07 stime=1614120134
cmdline="alarm07"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
alarm07.c:43: TPASS: Got 1 sigalarm in parent
alarm07.c:32: TPASS: alarm() request cleared in child

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=bpf_map01 stime=1614120137
cmdline="bpf_map01"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
bpf_common.c:18: TINFO: Raising RLIMIT_MEMLOCK to 2162688
bpf_map01.c:54: TPASS: Created hash map
bpf_map01.c:71: TPASS: Empty hash map lookup: ENOENT (2)
bpf_map01.c:105: TPASS: Update hash map element
bpf_map01.c:123: TPASS: hash map lookup
bpf_map01.c:54: TPASS: Created array map
bpf_map01.c:105: TPASS: Update array map element
bpf_map01.c:123: TPASS: array map lookup

Summary:
passed   7
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=bpf_prog02 stime=1614120137
cmdline="bpf_prog02"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
bpf_common.c:18: TINFO: Raising RLIMIT_MEMLOCK to 2162688
tst_capability.c:29: TINFO: Dropping CAP_SYS_ADMIN(21)
bpf_common.c:83: TPASS: Loaded program
bpf_prog02.c:119: TPASS: val = 1152921504606846976 + 1
bpf_prog02.c:136: TPASS: val = 1152921504606846976 - 1

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=capget02 stime=1614120137
cmdline="capget02"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
capget02.c:59: TPASS: capget() with bad address header: EFAULT (14)
capget02.c:59: TPASS: capget() with bad address data: EFAULT (14)
capget02.c:59: TPASS: capget() with bad version: EINVAL (22)
capget02.c:59: TPASS: capget() with bad pid: EINVAL (22)
capget02.c:59: TPASS: capget() with unused pid: ESRCH (3)

Summary:
passed   5
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=capset03 stime=1614120137
cmdline="capset03"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
capset03.c:24: TINFO: Test bad value data(when pI is not old pP or old pI without CAP_SETPCAP)
capset03.c:26: TPASS: capset(): EPERM (1)

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=chmod02 stime=1614120137
cmdline="chmod02"
contacts=""
analysis=exit
<<<test_output>>>
chmod02     1  TPASS  :  chmod(test_file, 0) returned 0
chmod02     2  TPASS  :  chmod(test_file, 07) returned 0
chmod02     3  TPASS  :  chmod(test_file, 070) returned 0
chmod02     4  TPASS  :  chmod(test_file, 0700) returned 0
chmod02     5  TPASS  :  chmod(test_file, 0777) returned 0
chmod02     6  TPASS  :  chmod(test_file, 02777) returned 0
chmod02     7  TPASS  :  chmod(test_file, 04777) returned 0
chmod02     8  TPASS  :  chmod(test_file, 06777) returned 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=chmod04 stime=1614120137
cmdline="chmod04"
contacts=""
analysis=exit
<<<test_output>>>
chmod04     1  TPASS  :  Functionality of chmod(testdir_4, 01777) successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=chown02 stime=1614120137
cmdline="chown02"
contacts=""
analysis=exit
<<<test_output>>>
chown02     1  TPASS  :  chown(testfile1, ..) succeeded
chown02     2  TPASS  :  chown(testfile2, ..) succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=chown04 stime=1614120137
cmdline="chown04"
contacts=""
analysis=exit
<<<test_output>>>
mke2fs 1.44.5 (15-Dec-2018)
chown04     0  TINFO  :  Found free device 0 '/dev/loop0'
chown04     0  TINFO  :  Formatting /dev/loop0 with ext2 opts='' extra opts=''
chown04     1  TPASS  :  chown failed: TEST_ERRNO=EPERM(1): Operation not permitted
chown04     2  TPASS  :  chown failed: TEST_ERRNO=EACCES(13): Permission denied
chown04     3  TPASS  :  chown failed: TEST_ERRNO=EFAULT(14): Bad address
chown04     4  TPASS  :  chown failed: TEST_ERRNO=ENAMETOOLONG(36): File name too long
chown04     5  TPASS  :  chown failed: TEST_ERRNO=ENOENT(2): No such file or directory
chown04     6  TPASS  :  chown failed: TEST_ERRNO=ENOTDIR(20): Not a directory
chown04     7  TPASS  :  chown failed: TEST_ERRNO=ELOOP(40): Too many levels of symbolic links
chown04     8  TPASS  :  chown failed: TEST_ERRNO=EROFS(30): Read-only file system
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=3
<<<test_end>>>
<<<test_start>>>
tag=clock_nanosleep04 stime=1614120137
cmdline="clock_nanosleep04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
clock_nanosleep04.c:33: TINFO: Testing variant: vDSO or syscall with libc spec
clock_nanosleep04.c:58: TPASS: clock_nanosleep(2) passed for clock CLOCK_MONOTONIC
clock_nanosleep04.c:58: TPASS: clock_nanosleep(2) passed for clock CLOCK_REALTIME
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
clock_nanosleep04.c:33: TINFO: Testing variant: syscall with old kernel spec
clock_nanosleep04.c:58: TPASS: clock_nanosleep(2) passed for clock CLOCK_MONOTONIC
clock_nanosleep04.c:58: TPASS: clock_nanosleep(2) passed for clock CLOCK_REALTIME

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=close02 stime=1614120137
cmdline="close02"
contacts=""
analysis=exit
<<<test_output>>>
close02     1  TPASS  :  call returned EBADF
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=close08 stime=1614120137
cmdline="close08"
contacts=""
analysis=exit
<<<test_output>>>
close08     1  TPASS  :  close(tfile_2693) returned 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=creat03 stime=1614120137
cmdline="creat03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
creat03.c:36: TINFO: Created file has mode = 0100674
creat03.c:41: TPASS: save text bit cleared

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=creat05 stime=1614120137
cmdline="creat05"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
creat05.c:49: TINFO: getdtablesize() = 1024
creat05.c:59: TINFO: Opened additional #1020 fds
creat05.c:36: TPASS: creat() failed with EMFILE

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=eventfd01 stime=1614120138
cmdline="eventfd01"
contacts=""
analysis=exit
<<<test_output>>>
eventfd01    1  TPASS  :  counter value matches required
eventfd01    2  TPASS  :  read failed with EAGAIN as expected
eventfd01    3  TPASS  :  counter value matches required
eventfd01    4  TPASS  :  write failed with EAGAIN as expected
eventfd01    5  TPASS  :  read failed with EINVAL as expected
eventfd01    6  TPASS  :  write failed with EINVAL as expected
eventfd01    7  TPASS  :  write failed with EINVAL as expected
eventfd01    8  TPASS  :  fd is set in readfds
eventfd01    9  TPASS  :  fd is not set in readfds
eventfd01   10  TPASS  :  fd is set in writefds
eventfd01   11  TPASS  :  fd is not set in writefds
eventfd01    1  TPASS  :  counter value matches required
eventfd01    2  TPASS  :  read failed with EAGAIN as expected
eventfd01    3  TPASS  :  counter value matches required
eventfd01    4  TPASS  :  write failed with EAGAIN as expected
eventfd01    5  TPASS  :  read failed with EINVAL as expected
eventfd01    6  TPASS  :  write failed with EINVAL as expected
eventfd01    7  TPASS  :  write failed with EINVAL as expected
eventfd01    8  TPASS  :  fd is set in readfds
eventfd01    9  TPASS  :  fd is not set in readfds
eventfd01   10  TPASS  :  fd is set in writefds
eventfd01   11  TPASS  :  fd is not set in writefds
eventfd01   12  TPASS  :  counter value write from child successful
eventfd01   13  TPASS  :  read fd set as expected
eventfd01   14  TPASS  :  POLLERR occurred as expected
eventfd01   15  TPASS  :  overflow occurred as expected
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=execve02 stime=1614120138
cmdline="execve02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
execve02.c:54: TPASS: execve() failed expectedly: EACCES (13)

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=execveat03 stime=1614120138
cmdline="execveat03"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
execveat_child.c:17: TPASS: execveat_child run as expected

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=exit_group01 stime=1614120138
cmdline="exit_group01"
contacts=""
analysis=exit
<<<test_output>>>
exit_group01    1  TPASS  :  exit_group() succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fallocate01 stime=1614120138
cmdline="fallocate01"
contacts=""
analysis=exit
<<<test_output>>>
fallocate01    1  TPASS  :  fallocate(4, 0, 49152, 4096) returned 0
fallocate01    2  TPASS  :  write operation on fallocated(4, 0, 49152, 4096) returned 1
fallocate01    3  TPASS  :  fallocate(5, 1, 49152, 4096) returned 0
fallocate01    4  TPASS  :  write operation on fallocated(5, 1, 49152, 4096) returned 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fallocate02 stime=1614120138
cmdline="fallocate02"
contacts=""
analysis=exit
<<<test_output>>>
fallocate02    1  TPASS  :  fallocate(test_file1:4, 1, 0, 1024) returned 9: TEST_ERRNO=EBADF(9): Bad file descriptor
fallocate02    2  TPASS  :  fallocate(test_file2:5, 1, -1024, 1024) returned 22: TEST_ERRNO=EINVAL(22): Invalid argument
fallocate02    3  TPASS  :  fallocate(test_file2:5, 1, 1024, -1024) returned 22: TEST_ERRNO=EINVAL(22): Invalid argument
fallocate02    4  TPASS  :  fallocate(test_file2:5, 1, 12288, 0) returned 22: TEST_ERRNO=EINVAL(22): Invalid argument
fallocate02    5  TPASS  :  fallocate(test_file2:5, 1, 12288, -1024) returned 22: TEST_ERRNO=EINVAL(22): Invalid argument
fallocate02    6  TPASS  :  fallocate(test_file2:5, 1, -24576, 1024) returned 22: TEST_ERRNO=EINVAL(22): Invalid argument
fallocate02    7  TPASS  :  fallocate(test_file2:5, 1, 9223372036854774784, 1024) returned 27: TEST_ERRNO=EFBIG(27): File too large
fallocate02    8  TPASS  :  fallocate(test_file2:5, 1, 1024, 9223372036854774784) returned 27: TEST_ERRNO=EFBIG(27): File too large
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fallocate04 stime=1614120138
cmdline="fallocate04"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '3072' bytes
fallocate04.c:86: TCONF: fallocate() not supported
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '3072' bytes
fallocate04.c:86: TCONF: fallocate() not supported
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '3072' bytes
fallocate04.c:96: TPASS: test-case succeeded
fallocate04.c:103: TINFO: read allocated file size '3072'
fallocate04.c:104: TINFO: make a hole with FALLOC_FL_PUNCH_HOLE
fallocate04.c:120: TINFO: check that file has a hole with lseek(,,SEEK_HOLE)
fallocate04.c:137: TINFO: found a hole at '1024' offset
fallocate04.c:143: TINFO: allocated file size before '3072' and after '2048'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:154: TPASS: test-case succeeded
fallocate04.c:159: TINFO: zeroing file space with FALLOC_FL_ZERO_RANGE
fallocate04.c:168: TINFO: read current allocated file size '2048'
fallocate04.c:185: TINFO: allocated file size before '2048' and after '3072'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:196: TPASS: test-case succeeded
fallocate04.c:201: TINFO: collapsing file space with FALLOC_FL_COLLAPSE_RANGE
fallocate04.c:205: TINFO: read current allocated file size '3072'
fallocate04.c:219: TINFO: allocated file size before '3072' and after '2048'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:236: TPASS: test-case succeeded
fallocate04.c:241: TINFO: inserting space with FALLOC_FL_INSERT_RANGE
fallocate04.c:245: TINFO: read current allocated file size '2048'
fallocate04.c:263: TINFO: allocated file size before '2048' and after '3072'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:274: TPASS: test-case succeeded
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '12288' bytes
fallocate04.c:96: TPASS: test-case succeeded
fallocate04.c:103: TINFO: read allocated file size '12288'
fallocate04.c:104: TINFO: make a hole with FALLOC_FL_PUNCH_HOLE
fallocate04.c:120: TINFO: check that file has a hole with lseek(,,SEEK_HOLE)
fallocate04.c:137: TINFO: found a hole at '4096' offset
fallocate04.c:143: TINFO: allocated file size before '12288' and after '8192'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:154: TPASS: test-case succeeded
fallocate04.c:159: TINFO: zeroing file space with FALLOC_FL_ZERO_RANGE
fallocate04.c:168: TINFO: read current allocated file size '8192'
fallocate04.c:185: TINFO: allocated file size before '8192' and after '12288'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:196: TPASS: test-case succeeded
fallocate04.c:201: TINFO: collapsing file space with FALLOC_FL_COLLAPSE_RANGE
fallocate04.c:205: TINFO: read current allocated file size '12288'
fallocate04.c:219: TINFO: allocated file size before '12288' and after '8192'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:236: TPASS: test-case succeeded
fallocate04.c:241: TINFO: inserting space with FALLOC_FL_INSERT_RANGE
fallocate04.c:245: TINFO: read current allocated file size '8192'
fallocate04.c:263: TINFO: allocated file size before '8192' and after '12288'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:274: TPASS: test-case succeeded
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '12288' bytes
fallocate04.c:96: TPASS: test-case succeeded
fallocate04.c:103: TINFO: read allocated file size '12288'
fallocate04.c:104: TINFO: make a hole with FALLOC_FL_PUNCH_HOLE
fallocate04.c:120: TINFO: check that file has a hole with lseek(,,SEEK_HOLE)
fallocate04.c:137: TINFO: found a hole at '4096' offset
fallocate04.c:143: TINFO: allocated file size before '12288' and after '8192'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:154: TPASS: test-case succeeded
fallocate04.c:159: TINFO: zeroing file space with FALLOC_FL_ZERO_RANGE
fallocate04.c:168: TINFO: read current allocated file size '8192'
fallocate04.c:185: TINFO: allocated file size before '8192' and after '12288'
fallocate04.c:66: TINFO: reading the file, compare with expected buffer
fallocate04.c:196: TPASS: test-case succeeded
fallocate04.c:201: TINFO: collapsing file space with FALLOC_FL_COLLAPSE_RANGE
fallocate04.c:205: TINFO: read current allocated file size '12288'
fallocate04.c:211: TCONF: FALLOC_FL_COLLAPSE_RANGE not supported
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:859: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '12288' bytes
fallocate04.c:96: TPASS: test-case succeeded
fallocate04.c:103: TINFO: read allocated file size '12288'
fallocate04.c:104: TINFO: make a hole with FALLOC_FL_PUNCH_HOLE
fallocate04.c:115: TCONF: FALLOC_FL_PUNCH_HOLE not supported
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
tst_test.c:870: TINFO: Trying FUSE...
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fallocate04.c:82: TINFO: allocate '12288' bytes
fallocate04.c:86: TCONF: fallocate() not supported

Summary:
passed   14
failed   0
broken   0
skipped  5
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=5 termination_type=exited termination_id=0 corefile=no
cutime=7 cstime=107
<<<test_end>>>
<<<test_start>>>
tag=posix_fadvise03_64 stime=1614120143
cmdline="posix_fadvise03_64"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
posix_fadvise03.c:86: TPASS: skipping defined - advise = 0
posix_fadvise03.c:86: TPASS: skipping defined - advise = 1
posix_fadvise03.c:86: TPASS: skipping defined - advise = 2
posix_fadvise03.c:86: TPASS: skipping defined - advise = 3
posix_fadvise03.c:86: TPASS: skipping defined - advise = 4
posix_fadvise03.c:86: TPASS: skipping defined - advise = 5
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 6 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 7 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 8 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 9 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 10 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 11 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 12 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 13 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 14 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 15 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 16 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 17 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 18 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 19 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 20 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 21 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 22 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 23 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 24 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 25 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 26 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 27 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 28 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 29 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 30 : EINVAL
posix_fadvise03.c:104: TPASS: expected failure - returned value = 22, advise = 31 : EINVAL

Summary:
passed   32
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=posix_fadvise04 stime=1614120143
cmdline="posix_fadvise04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE
posix_fadvise04.c:59: TPASS: expected failure - returned value = 29 : ESPIPE

Summary:
passed   6
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fchown01_16 stime=1614120143
cmdline="fchown01_16"
contacts=""
analysis=exit
<<<test_output>>>
fchown01_16    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/fchown/../utils/compat_16.h:156: 16-bit version of fchown() is not supported on your platform
fchown01_16    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/fchown/../utils/compat_16.h:156: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fchown02_16 stime=1614120143
cmdline="fchown02_16"
contacts=""
analysis=exit
<<<test_output>>>
fchown02_16    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/fchown/../utils/compat_16.h:156: 16-bit version of fchown() is not supported on your platform
fchown02_16    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/fchown/../utils/compat_16.h:156: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl02 stime=1614120144
cmdline="fcntl02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 0) returned 5
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 1) returned 5
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 2) returned 5
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 3) returned 5
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 10) returned 10
fcntl02.c:42: TPASS: fcntl(fcntl02_2832, F_DUPFD, 100) returned 100

Summary:
passed   6
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl03_64 stime=1614120144
cmdline="fcntl03_64"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fcntl03.c:33: TPASS: fcntl(fcntl03_2834, F_GETFD, 0) returned 0

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl04 stime=1614120144
cmdline="fcntl04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fcntl04.c:39: TPASS: fcntl(fcntl04_2836, F_GETFL, 0) returned 8002

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl08 stime=1614120144
cmdline="fcntl08"
contacts=""
analysis=exit
<<<test_output>>>
fcntl08     1  TPASS  :  fcntl returned 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl13 stime=1614120144
cmdline="fcntl13"
contacts=""
analysis=exit
<<<test_output>>>
fcntl13     1  TPASS  :  got EINVAL
fcntl13     2  TPASS  :  F_SETLK: got EFAULT
fcntl13     3  TPASS  :  F_SETLKW: got EFAULT
fcntl13     4  TPASS  :  F_GETLK: got EFAULT
fcntl13     5  TPASS  :  got EINVAL
fcntl13     6  TPASS  :  got EBADFD
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl15 stime=1614120144
cmdline="fcntl15"
contacts=""
analysis=exit
<<<test_output>>>
fcntl15     1  TPASS  :  Test 1: test with "dup" PASSED
fcntl15     0  TINFO  :  Failed to record test working dir
fcntl15     2  TPASS  :  Test 2: test with "open" PASSED
fcntl15     0  TINFO  :  Failed to record test working dir
fcntl15     3  TPASS  :  Test 3: test with "fork" PASSED
<<<execution_status>>>
initiation_status="ok"
duration=10 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl17_64 stime=1614120154
cmdline="fcntl17_64"
contacts=""
analysis=exit
<<<test_output>>>
fcntl17     0  TINFO  :  Enter preparation phase
fcntl17     0  TINFO  :  child 3 starting
fcntl17     0  TINFO  :  child 3 pid 2880 locked
fcntl17     0  TINFO  :  child 3 resuming
fcntl17     0  TINFO  :  child 3 lockw err 35
fcntl17     0  TINFO  :  child 3 exiting
fcntl17     0  TINFO  :  child 1 starting
fcntl17     0  TINFO  :  child 1 pid 2878 locked
fcntl17     0  TINFO  :  child 1 resuming
fcntl17     0  TINFO  :  child 1 unlocked
fcntl17     0  TINFO  :  child 1 exiting
fcntl17     0  TINFO  :  child 2 starting
fcntl17     0  TINFO  :  child 2 pid 2879 locked
fcntl17     0  TINFO  :  child 2 resuming
fcntl17     0  TINFO  :  child 2 lockw locked
fcntl17     0  TINFO  :  child 2 exiting
fcntl17     0  TINFO  :  Exit preparation phase
fcntl17     0  TINFO  :  Enter block 1
fcntl17     1  TPASS  :  Block 1 PASSED
fcntl17     0  TINFO  :  Exit block 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=fcntl19 stime=1614120154
cmdline="fcntl19"
contacts=""
analysis=exit
<<<test_output>>>
fcntl19     0  TINFO  :  Enter block 1
fcntl19     0  TINFO  :  Test block 1: PASSED
fcntl19     0  TINFO  :  Exit block 1
fcntl19     0  TINFO  :  Enter block 2
fcntl19     0  TINFO  :  Test block 2: PASSED
fcntl19     0  TINFO  :  Exit block 2
fcntl19     0  TINFO  :  Enter block 3
fcntl19     0  TINFO  :  Test block 3: PASSED
fcntl19     0  TINFO  :  Exit block 3
fcntl19     0  TINFO  :  Enter blcok 4
fcntl19     0  TINFO  :  Test block 4: PASSED
fcntl19     0  TINFO  :  Exit block 4
fcntl19     0  TINFO  :  Enter block 5
fcntl19     0  TINFO  :  Test block 5: PASSED
fcntl19     0  TINFO  :  Exit block 5
fcntl19     0  TINFO  :  Enter block 6
fcntl19     0  TINFO  :  Test block 6: PASSED
fcntl19     0  TINFO  :  Exit block 6
fcntl19     0  TINFO  :  Enter block 7
fcntl19     0  TINFO  :  Test block 7: PASSED
fcntl19     0  TINFO  :  Exit block 7
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl20 stime=1614120154
cmdline="fcntl20"
contacts=""
analysis=exit
<<<test_output>>>
fcntl20     0  TINFO  :  Enter block 1
fcntl20     0  TINFO  :  Test block 1: PASSED
fcntl20     0  TINFO  :  Exit block 1
fcntl20     0  TINFO  :  Enter block 2
fcntl20     0  TINFO  :  Test block 2: PASSED
fcntl20     0  TINFO  :  Exit block 2
fcntl20     0  TINFO  :  Enter block 3
fcntl20     0  TINFO  :  Test block 3: PASSED
fcntl20     0  TINFO  :  Exit block 3
fcntl20     0  TINFO  :  Enter blcok 4
fcntl20     0  TINFO  :  Test block 4: PASSED
fcntl20     0  TINFO  :  Exit block 4
fcntl20     0  TINFO  :  Enter block 5
fcntl20     0  TINFO  :  Test block 5: PASSED
fcntl20     0  TINFO  :  Exit block 5
fcntl20     0  TINFO  :  Enter block 6
fcntl20     0  TINFO  :  Test block 6: PASSED
fcntl20     0  TINFO  :  Exit block 6
fcntl20     0  TINFO  :  Enter block 7
fcntl20     0  TINFO  :  Test block 7: PASSED
fcntl20     0  TINFO  :  Exit block 7
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl20_64 stime=1614120154
cmdline="fcntl20_64"
contacts=""
analysis=exit
<<<test_output>>>
fcntl20     0  TINFO  :  Enter block 1
fcntl20     0  TINFO  :  Test block 1: PASSED
fcntl20     0  TINFO  :  Exit block 1
fcntl20     0  TINFO  :  Enter block 2
fcntl20     0  TINFO  :  Test block 2: PASSED
fcntl20     0  TINFO  :  Exit block 2
fcntl20     0  TINFO  :  Enter block 3
fcntl20     0  TINFO  :  Test block 3: PASSED
fcntl20     0  TINFO  :  Exit block 3
fcntl20     0  TINFO  :  Enter blcok 4
fcntl20     0  TINFO  :  Test block 4: PASSED
fcntl20     0  TINFO  :  Exit block 4
fcntl20     0  TINFO  :  Enter block 5
fcntl20     0  TINFO  :  Test block 5: PASSED
fcntl20     0  TINFO  :  Exit block 5
fcntl20     0  TINFO  :  Enter block 6
fcntl20     0  TINFO  :  Test block 6: PASSED
fcntl20     0  TINFO  :  Exit block 6
fcntl20     0  TINFO  :  Enter block 7
fcntl20     0  TINFO  :  Test block 7: PASSED
fcntl20     0  TINFO  :  Exit block 7
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl26 stime=1614120154
cmdline="fcntl26"
contacts=""
analysis=exit
<<<test_output>>>
fcntl26     1  TPASS  :  fcntl(tfile_2887, F_SETLEASE, F_WRLCK)
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl28_64 stime=1614120154
cmdline="fcntl28_64"
contacts=""
analysis=exit
<<<test_output>>>
fcntl28     1  TPASS  :  fcntl(fd, F_SETLEASE, F_RDLCK) succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl31 stime=1614120154
cmdline="fcntl31"
contacts=""
analysis=exit
<<<test_output>>>
fcntl31     0  TINFO  :  default io events signal is SIGIO
fcntl31     1  TPASS  :  fcntl test F_GETOWN, F_SETOWN for process ID success
fcntl31     0  TINFO  :  default io events signal is SIGIO
fcntl31     2  TPASS  :  fcntl test F_GETOWN, F_SETOWN for process group ID success
fcntl31     0  TINFO  :  default io events signal is SIGIO
fcntl31     3  TPASS  :  fcntl test F_GETOWN_EX, F_SETOWN_EX for thread ID success
fcntl31     0  TINFO  :  default io events signal is SIGIO
fcntl31     4  TPASS  :  fcntl test F_GETOWN_EX, F_SETOWN_EX for process ID success
fcntl31     0  TINFO  :  default io events signal is SIGIO
fcntl31     5  TPASS  :  fcntl test F_GETOWN_EX, F_SETOWN_EX for process group ID success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fcntl34_64 stime=1614120154
cmdline="fcntl34_64"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fcntl34.c:90: TINFO: write to a file inside threads with OFD locks
fcntl34.c:36: TINFO: spawning '12' threads
fcntl34.c:45: TINFO: waiting for '12' threads
fcntl34.c:99: TINFO: verifying file's data
fcntl34.c:127: TPASS: OFD locks synchronized access between threads

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=fcntl37 stime=1614120154
cmdline="fcntl37"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_capability.c:29: TINFO: Dropping CAP_SYS_RESOURCE(24)
fcntl37.c:42: TINFO: F_SETPIPE_SZ and size is beyond 1<<31
fcntl37.c:50: TPASS: F_SETPIPE_SZ failed as expected: EINVAL (22)
fcntl37.c:42: TINFO: F_SETPIPE_SZ and size < data stored in pipe
fcntl37.c:50: TPASS: F_SETPIPE_SZ failed as expected: EBUSY (16)
fcntl37.c:42: TINFO: F_SETPIPE_SZ and size is over limit for unpriviledged user
fcntl37.c:50: TPASS: F_SETPIPE_SZ failed as expected: EPERM (1)

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fgetxattr01 stime=1614120154
cmdline="fgetxattr01"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:859: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:122: TCONF: no xattr support in fs or mounted without user_xattr option
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
tst_test.c:870: TINFO: Trying FUSE...
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ENODATA (61)
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: ERANGE (34)
fgetxattr01.c:88: TPASS: fgetxattr(2) passed
fgetxattr01.c:98: TPASS: got the right value
fgetxattr01.c:102: TPASS: fgetxattr(2) passed: SUCCESS (0)

Summary:
passed   30
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=7 cstime=106
<<<test_end>>>
<<<test_start>>>
tag=fgetxattr02 stime=1614120158
cmdline="fgetxattr02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fgetxattr02.c:174: TPASS: fgetxattr(2) on testfile passed
fgetxattr02.c:188: TPASS: fgetxattr(2) on testfile got the right value
fgetxattr02.c:201: TPASS: fgetxattr(2) on testfile passed: SUCCESS (0)
fgetxattr02.c:174: TPASS: fgetxattr(2) on testdir passed
fgetxattr02.c:188: TPASS: fgetxattr(2) on testdir got the right value
fgetxattr02.c:201: TPASS: fgetxattr(2) on testdir passed: SUCCESS (0)
fgetxattr02.c:174: TPASS: fgetxattr(2) on symlink passed
fgetxattr02.c:188: TPASS: fgetxattr(2) on symlink got the right value
fgetxattr02.c:201: TPASS: fgetxattr(2) on symlink passed: SUCCESS (0)
fgetxattr02.c:201: TPASS: fgetxattr(2) on fifo passed: ENODATA (61)
fgetxattr02.c:201: TPASS: fgetxattr(2) on chr passed: ENODATA (61)
fgetxattr02.c:201: TPASS: fgetxattr(2) on blk passed: ENODATA (61)
fgetxattr02.c:201: TPASS: fgetxattr(2) on sock passed: ENODATA (61)

Summary:
passed   13
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fork02 stime=1614120158
cmdline="fork02"
contacts=""
analysis=exit
<<<test_output>>>
fork02      0  TINFO  :  Inside parent
fork02      0  TINFO  :  exit status of wait 0
fork02      1  TPASS  :  test 1 PASSED
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fork03 stime=1614120158
cmdline="fork03"
contacts=""
analysis=exit
<<<test_output>>>
fork03      0  TINFO  :  process id in parent of child from fork : 3017
fork03      1  TPASS  :  test 1 PASSED
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fork14 stime=1614120158
cmdline="fork14"
contacts=""
analysis=exit
<<<test_output>>>
fork14      1  TPASS  :  fork failed as expected.
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=30
<<<test_end>>>
<<<test_start>>>
tag=fpathconf01 stime=1614120158
cmdline="fpathconf01"
contacts=""
analysis=exit
<<<test_output>>>
fpathconf01    1  TPASS  :  fpathconf(fd, _PC_MAX_CANON) returned 255
fpathconf01    2  TPASS  :  fpathconf(fd, _PC_MAX_INPUT) returned 255
fpathconf01    3  TPASS  :  fpathconf(fd, _PC_VDISABLE) returned 0
fpathconf01    4  TPASS  :  fpathconf(fd, _PC_LINK_MAX) returned 32000
fpathconf01    5  TPASS  :  fpathconf(fd, _PC_NAME_MAX) returned 255
fpathconf01    6  TPASS  :  fpathconf(fd, _PC_PATH_MAX) returned 4096
fpathconf01    7  TPASS  :  fpathconf(fd, _PC_PIPE_BUF) returned 4096
fpathconf01    8  TPASS  :  fpathconf(fd, _PC_CHOWN_RESTRICTED) returned 1
fpathconf01    9  TPASS  :  fpathconf(fd, _PC_NO_TRUNC) returned 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getdtablesize01 stime=1614120158
cmdline="getdtablesize01"
contacts=""
analysis=exit
<<<test_output>>>
getdtablesize01    0  TINFO  :  Maximum number of files a process can have opened is 1024
getdtablesize01    0  TINFO  :  Checking with the value returned by getrlimit...RLIMIT_NOFILE
getdtablesize01    1  TPASS  :  got correct dtablesize, value is 1024
getdtablesize01    0  TINFO  :  Checking Max num of files that can be opened by a process.Should be: RLIMIT_NOFILE - 1
getdtablesize01    2  TPASS  :  1023 = 1023
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getegid02 stime=1614120158
cmdline="getegid02"
contacts=""
analysis=exit
<<<test_output>>>
getegid02    1  TPASS  :  effective group id 0 is correct
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=gethostbyname_r01 stime=1614120158
cmdline="gethostbyname_r01"
contacts=""
analysis=exit
<<<test_output>>>
gethostbyname_r01    1  TPASS  :  not vulnerable
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getpgid01 stime=1614120158
cmdline="getpgid01"
contacts=""
analysis=exit
<<<test_output>>>
getpgid01    0  TINFO  :  Enter block 1
getpgid01    1  TPASS  :  Test block 1: getpgid(0) PASSED
getpgid01    0  TINFO  :  Exit block 1
getpgid01    0  TINFO  :  Enter block 2
getpgid01    2  TPASS  :  Test block 2: getpgid(getpid()) PASSED
getpgid01    0  TINFO  :  Exit block 2
getpgid01    0  TINFO  :  Enter block 3
getpgid01    3  TPASS  :  Test block 3: getpgid(getppid()) PASSED
getpgid01    0  TINFO  :  Exit block 3
getpgid01    0  TINFO  :  Enter block 4
getpgid01    4  TPASS  :  Test block 4: getpgid(1) PASSED
getpgid01    0  TINFO  :  Exit block 4
getpgid01    0  TINFO  :  Enter block 5
getpgid01    5  TPASS  :  Test block 5: getpgid(1) PASSED
getpgid01    0  TINFO  :  Exit block 5
getpgid01    0  TINFO  :  getpgid01 PASSED
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getppid01 stime=1614120158
cmdline="getppid01"
contacts=""
analysis=exit
<<<test_output>>>
getppid01    1  TPASS  :  getppid returned 2654
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getpriority01 stime=1614120158
cmdline="getpriority01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
getpriority01.c:50: TPASS: getpriority(0, 0) returned 0
getpriority01.c:50: TPASS: getpriority(1, 0) returned 0
getpriority01.c:50: TPASS: getpriority(2, 0) returned -20

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getresgid01 stime=1614120158
cmdline="getresgid01"
contacts=""
analysis=exit
<<<test_output>>>
getresgid01    1  TPASS  :  Functionality of getresgid() successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=getresgid01_16 stime=1614120158
cmdline="getresgid01_16"
contacts=""
analysis=exit
<<<test_output>>>
getresgid01    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/getresgid/../utils/compat_16.h:151: 16-bit version of getresgid() is not supported on your platform
getresgid01    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/getresgid/../utils/compat_16.h:151: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getresgid02 stime=1614120158
cmdline="getresgid02"
contacts=""
analysis=exit
<<<test_output>>>
getresgid02    1  TPASS  :  Functionality of getresgid() successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getresuid01_16 stime=1614120158
cmdline="getresuid01_16"
contacts=""
analysis=exit
<<<test_output>>>
getresuid01    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/getresuid/../utils/compat_16.h:141: 16-bit version of getresuid() is not supported on your platform
getresuid01    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/getresuid/../utils/compat_16.h:141: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getrusage03 stime=1614120158
cmdline="getrusage03"
contacts=""
analysis=exit
<<<test_output>>>
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    0  TINFO  :  child.self = 102504
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    1  TPASS  :  initial.self ~= child.self
getrusage03    0  TINFO  :  Testcase #02: fork inherit(cont.)
getrusage03    0  TINFO  :  initial.children = 103612
getrusage03    2  TPASS  :  initial.children ~= 100MB
getrusage03    0  TINFO  :  child.children = 0
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    1  TPASS  :  initial.self ~= child.self
getrusage03    0  TINFO  :  Testcase #02: fork inherit(cont.)
getrusage03    0  TINFO  :  initial.children = 103612
getrusage03    2  TPASS  :  initial.children ~= 100MB
getrusage03    3  TPASS  :  child.children == 0
getrusage03    0  TINFO  :  Testcase #03: fork + malloc
getrusage03    0  TINFO  :  initial.self = 104128
getrusage03    0  TINFO  :  child allocate +50MB
getrusage03    0  TINFO  :  child.self = 154320
getrusage03_child    0  TINFO  :  grandchild allocate 300MB
getrusage03_child    0  TINFO  :  grandchild allocate 300MB
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    1  TPASS  :  initial.self ~= child.self
getrusage03    0  TINFO  :  Testcase #02: fork inherit(cont.)
getrusage03    0  TINFO  :  initial.children = 103612
getrusage03    2  TPASS  :  initial.children ~= 100MB
getrusage03    3  TPASS  :  child.children == 0
getrusage03    0  TINFO  :  Testcase #03: fork + malloc
getrusage03    0  TINFO  :  initial.self = 104128
getrusage03    4  TPASS  :  initial.self + 50MB ~= child.self
getrusage03    0  TINFO  :  Testcase #04: grandchild maxrss
getrusage03    0  TINFO  :  initial.children = 154816
getrusage03_child    0  TINFO  :  child allocate 400MB
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    1  TPASS  :  initial.self ~= child.self
getrusage03    0  TINFO  :  Testcase #02: fork inherit(cont.)
getrusage03    0  TINFO  :  initial.children = 103612
getrusage03    2  TPASS  :  initial.children ~= 100MB
getrusage03    3  TPASS  :  child.children == 0
getrusage03    0  TINFO  :  Testcase #03: fork + malloc
getrusage03    0  TINFO  :  initial.self = 104128
getrusage03    4  TPASS  :  initial.self + 50MB ~= child.self
getrusage03    0  TINFO  :  Testcase #04: grandchild maxrss
getrusage03    0  TINFO  :  initial.children = 154816
getrusage03    0  TINFO  :  post_wait.children = 308148
getrusage03    5  TPASS  :  child.children ~= 300MB
getrusage03    0  TINFO  :  Testcase #05: zombie
getrusage03    0  TINFO  :  initial.children = 308148
getrusage03_child    0  TINFO  :  child allocate 500MB
getrusage03    0  TINFO  :  allocate 100MB
getrusage03    0  TINFO  :  Testcase #01: fork inherit
getrusage03    0  TINFO  :  initial.self = 103884
getrusage03    1  TPASS  :  initial.self ~= child.self
getrusage03    0  TINFO  :  Testcase #02: fork inherit(cont.)
getrusage03    0  TINFO  :  initial.children = 103612
getrusage03    2  TPASS  :  initial.children ~= 100MB
getrusage03    3  TPASS  :  child.children == 0
getrusage03    0  TINFO  :  Testcase #03: fork + malloc
getrusage03    0  TINFO  :  initial.self = 104128
getrusage03    4  TPASS  :  initial.self + 50MB ~= child.self
getrusage03    0  TINFO  :  Testcase #04: grandchild maxrss
getrusage03    0  TINFO  :  initial.children = 154816
getrusage03    0  TINFO  :  post_wait.children = 308148
getrusage03    5  TPASS  :  child.children ~= 300MB
getrusage03    0  TINFO  :  Testcase #05: zombie
getrusage03    0  TINFO  :  initial.children = 308148
getrusage03    0  TINFO  :  pre_wait.children = 308148
getrusage03    6  TPASS  :  initial.children ~= pre_wait.children
getrusage03    0  TINFO  :  post_wait.children = 411284
getrusage03    7  TPASS  :  post_wait.children ~= 400MB
getrusage03    0  TINFO  :  Testcase #06: SIG_IGN
getrusage03    0  TINFO  :  initial.children = 411284
getrusage03_child    0  TINFO  :  exec.self = 104144, exec.children = 411284
getrusage03_child    1  TPASS  :  initial.self ~= exec.self
getrusage03_child    2  TPASS  :  initial.children ~= exec.children
<<<execution_status>>>
initiation_status="ok"
duration=3 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=7
<<<test_end>>>
<<<test_start>>>
tag=getsockopt01 stime=1614120161
cmdline="getsockopt01"
contacts=""
analysis=exit
<<<test_output>>>
getsockopt01    1  TPASS  :  bad file descriptor successful
getsockopt01    2  TPASS  :  bad file descriptor successful
getsockopt01    3  TPASS  :  invalid option buffer successful
getsockopt01    4  TPASS  :  invalid optlen successful
getsockopt01    5  TPASS  :  invalid level successful
getsockopt01    6  TPASS  :  invalid option name successful
getsockopt01    7  TPASS  :  invalid option name (UDP) successful
getsockopt01    8  TPASS  :  invalid option name (IP) successful
getsockopt01    9  TPASS  :  invalid option name (TCP) successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=getuid03 stime=1614120161
cmdline="getuid03"
contacts=""
analysis=exit
<<<test_output>>>
getuid03    1  TPASS  :  values from getuid and getpwuid match
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ioctl03 stime=1614120161
cmdline="ioctl03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
ioctl03.c:76: TINFO: Available features are: 0x7133
ioctl03.c:81: TPASS: TUN 0x1
ioctl03.c:81: TPASS: TAP 0x2
ioctl03.c:81: TPASS: NO_PI 0x1000
ioctl03.c:81: TPASS: ONE_QUEUE 0x2000
ioctl03.c:81: TPASS: VNET_HDR 0x4000
ioctl03.c:81: TPASS: MULTI_QUEUE 0x100
ioctl03.c:81: TPASS: IFF_NAPI 0x10
ioctl03.c:81: TPASS: IFF_NAPI_FRAGS 0x20

Summary:
passed   8
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ioctl05 stime=1614120161
cmdline="ioctl05"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
ioctl05.c:35: TPASS: BLKGETSIZE returned 524288, BLKGETSIZE64 268435456
ioctl05.c:46: TPASS: Could lseek to the end of the device
ioctl05.c:53: TPASS: Got EOF when trying to read after the end of device

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=ioctl09 stime=1614120161
cmdline="ioctl09"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
ioctl09.c:45: TPASS: access /sys/block/loop0/loop0p1 succeeds
ioctl09.c:53: TPASS: access /dev/loop0p1 succeeds
ioctl09.c:48: TPASS: access /sys/block/loop0/loop0p2 fails
ioctl09.c:56: TPASS: access /dev/loop0p2 fails
ioctl09.c:45: TPASS: access /sys/block/loop0/loop0p1 succeeds
ioctl09.c:53: TPASS: access /dev/loop0p1 succeeds
ioctl09.c:45: TPASS: access /sys/block/loop0/loop0p2 succeeds
ioctl09.c:53: TPASS: access /dev/loop0p2 succeeds

Summary:
passed   8
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=3 cstime=4
<<<test_end>>>
<<<test_start>>>
tag=ioctl_loop04 stime=1614120161
cmdline="ioctl_loop04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
ioctl_loop04.c:35: TPASS: /sys/block/loop0/size = 20
ioctl_loop04.c:50: TPASS: LOOP_SET_CAPACITY set loop size to 5120
ioctl_loop04.c:56: TPASS: /sys/block/loop0/size = 10

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=ioctl_ns07 stime=1614120161
cmdline="ioctl_ns07"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
ioctl_ns07.c:33: TPASS: request failed with ENOTTY
ioctl_ns07.c:33: TPASS: request failed with ENOTTY
ioctl_ns07.c:33: TPASS: request failed with ENOTTY
ioctl_ns07.c:33: TPASS: request failed with ENOTTY

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=inotify02 stime=1614120161
cmdline="inotify02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
inotify02.c:185: TPASS: get event: wd=1 mask=40000004 cookie=0     len=0  name=""
inotify02.c:185: TPASS: get event: wd=1 mask=00000100 cookie=0     len=16 name="test_file1"
inotify02.c:185: TPASS: get event: wd=1 mask=00000020 cookie=0     len=16 name="test_file1"
inotify02.c:185: TPASS: get event: wd=1 mask=00000008 cookie=0     len=16 name="test_file1"
inotify02.c:185: TPASS: get event: wd=1 mask=00000040 cookie=5338  len=16 name="test_file1"
inotify02.c:185: TPASS: get event: wd=1 mask=00000080 cookie=5338  len=16 name="test_file2"
inotify02.c:185: TPASS: get event: wd=1 mask=00000800 cookie=0     len=0  name=""
inotify02.c:185: TPASS: get event: wd=1 mask=00000200 cookie=0     len=16 name="test_file2"
inotify02.c:185: TPASS: get event: wd=1 mask=00000800 cookie=0     len=0  name=""

Summary:
passed   9
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=inotify05 stime=1614120161
cmdline="inotify05"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
inotify05.c:115: TPASS: get event: wd=-1 mask=4000 cookie=0 len=0

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=4
<<<test_end>>>
<<<test_start>>>
tag=fanotify04 stime=1614120161
cmdline="fanotify04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify04.c:70: TPASS: fanotify_mark (4, FAN_MARK_ADD | FAN_MARK_ONLYDIR, FAN_OPEN, AT_FDCWD, '.') succeeded
fanotify04.c:70: TPASS: fanotify_mark (4, FAN_MARK_ADD | FAN_MARK_ONLYDIR, FAN_OPEN, AT_FDCWD, 'fname_3120') failed
fanotify04.c:70: TPASS: fanotify_mark (4, FAN_MARK_ADD | FAN_MARK_DONT_FOLLOW, FAN_OPEN, AT_FDCWD, 'symlink_3120') succeeded
fanotify04.c:162: TPASS: No event as expected
fanotify04.c:70: TPASS: fanotify_mark (4, FAN_MARK_ADD | 0, FAN_OPEN, AT_FDCWD, 'symlink_3120') succeeded
fanotify04.c:126: TPASS: event generated properly for type 100000
fanotify04.c:126: TPASS: event generated properly for type 100000
fanotify04.c:126: TPASS: event generated properly for type 40000
fanotify04.c:162: TPASS: No event as expected

Summary:
passed   9
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=fanotify13 stime=1614120161
cmdline="fanotify13"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = f8054a03.c1058462.c.3a6de20f.0...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = f8054a03.c1058462.d.3a6de210.0...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = f8054a03.c1058462.5001.3a6de211.0...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3145, fid=f8054a03.c1058462.3a6de21100005001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3145, fid=f8054a03.c1058462.3a6de21100005001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de20f0000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3145, fid=f8054a03.c1058462.3a6de2100000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3145, fid=f8054a03.c1058462.3a6de21100005001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = 75140d4b.1b92b5ca.1801.9c961886.0...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = 75140d4b.1b92b5ca.1802.c4183ff5.0...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = 75140d4b.1b92b5ca.3001.638063aa.0...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3156, fid=75140d4b.1b92b5ca.638063aa00003001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3156, fid=75140d4b.1b92b5ca.638063aa00003001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.9c96188600001801 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3156, fid=75140d4b.1b92b5ca.c4183ff500001802 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3156, fid=75140d4b.1b92b5ca.638063aa00003001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = 11e549f8.789cc5c1.c.6ec59006.0...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = 11e549f8.789cc5c1.d.5874b2c.0...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = 11e549f8.789cc5c1.8001.e8fb8c17.0...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3164, fid=11e549f8.789cc5c1.e8fb8c1700008001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3164, fid=11e549f8.789cc5c1.e8fb8c1700008001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.6ec590060000000c values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3164, fid=11e549f8.789cc5c1.5874b2c0000000d values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3164, fid=11e549f8.789cc5c1.e8fb8c1700008001 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = 700.0.83.0.56b1600a...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = 700.0.84.0.c3313163...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = 700.0.85.0.8f3e460d...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3176, fid=700.0.85 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3176, fid=700.0.85 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.83 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3176, fid=700.0.84 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3176, fid=700.0.85 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = 41b0b8da.12a0ac8.101.0.5...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = 41b0b8da.12a0ac8.102.0.5...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = 41b0b8da.12a0ac8.103.0.5...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3204, fid=41b0b8da.12a0ac8.103 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3204, fid=41b0b8da.12a0ac8.103 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.101 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3204, fid=41b0b8da.12a0ac8.102 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3204, fid=41b0b8da.12a0ac8.103 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:859: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify.h:237: TINFO: fid(mntpoint/file_one) = 700.0.73.72f57ac3.0...
fanotify.h:237: TINFO: fid(mntpoint/file_two) = 700.0.74.a2983e6b.0...
fanotify.h:237: TINFO: fid(mntpoint/dir_one) = 700.0.75.cc03ecc0.0...
fanotify13.c:143: TINFO: Test #0: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #1: FAN_REPORT_FID with mark flag: FAN_MARK_INODE
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3206, fid=700.0.cc03ecc000000075 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #2: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #3: FAN_REPORT_FID with mark flag: FAN_MARK_MOUNT
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3206, fid=700.0.cc03ecc000000075 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #4: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:143: TINFO: Test #5: FAN_REPORT_FID with mark flag: FAN_MARK_FILESYSTEM
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.72f57ac300000073 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=30, pid=3206, fid=700.0.a2983e6b00000074 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
fanotify13.c:251: TPASS: got event: mask=40000030, pid=3206, fid=700.0.cc03ecc000000075 values returned in event match those returned in statfs(2) and name_to_handle_at(2)
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
tst_test.c:870: TINFO: Trying FUSE...
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
fanotify13.c:259: TCONF: FAN_REPORT_FID not supported on ntfs filesystem

Summary:
passed   90
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=5 termination_type=exited termination_id=0 corefile=no
cutime=7 cstime=107
<<<test_end>>>
<<<test_start>>>
tag=keyctl01 stime=1614120166
cmdline="keyctl01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
keyctl01.c:27: TPASS: KEYCTL_GET_KEYRING_ID succeeded
keyctl01.c:48: TPASS: KEYCTL_REVOKE failed as expected: ENOKEY (126)

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=kcmp02 stime=1614120166
cmdline="kcmp02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
kcmp.h:49: TCONF: syscall(312) __NR_kcmp not supported

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=kcmp03 stime=1614120166
cmdline="kcmp03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
kcmp.h:49: TCONF: syscall(312) __NR_kcmp not supported
kcmp.h:49: TCONF: syscall(312) __NR_kcmp not supported
kcmp.h:49: TCONF: syscall(312) __NR_kcmp not supported
kcmp.h:49: TCONF: syscall(312) __NR_kcmp not supported

Summary:
passed   0
failed   0
broken   0
skipped  4
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=link06 stime=1614120166
cmdline="link06"
contacts=""
analysis=exit
<<<test_output>>>
link06      1  TPASS  :  link() fails with expected error EACCES errno:13
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=link07 stime=1614120166
cmdline="link07"
contacts=""
analysis=exit
<<<test_output>>>
link07      1  TPASS  :  link() fails with expected error: TEST_ERRNO=EACCES(13): Permission denied
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=llistxattr03 stime=1614120166
cmdline="llistxattr03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
llistxattr03.c:55: TPASS: llistxattr() succeed with suitable buffer
llistxattr03.c:55: TPASS: llistxattr() succeed with suitable buffer

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=lremovexattr01 stime=1614120166
cmdline="lremovexattr01"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:859: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:115: TCONF: symlink() not supported
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
tst_test.c:870: TINFO: Trying FUSE...
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lremovexattr01.c:107: TPASS: lremovexattr(2) removed attribute as expected

Summary:
passed   6
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=5 termination_type=exited termination_id=0 corefile=no
cutime=8 cstime=105
<<<test_end>>>
<<<test_start>>>
tag=lseek01 stime=1614120171
cmdline="lseek01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lseek01.c:67: TPASS: lseek(tfile, 4, SEEK_SET) read correct data
lseek01.c:67: TPASS: lseek(tfile, -2, SEEK_CUR) read correct data
lseek01.c:67: TPASS: lseek(tfile, -4, SEEK_END) read correct data
lseek01.c:67: TPASS: lseek(tfile, 0, SEEK_END) read correct data

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=lseek07 stime=1614120171
cmdline="lseek07"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
lseek07.c:70: TPASS: lseek(tfile1, 7, SEEK_SET) wrote correct data abcdefgijk
lseek07.c:70: TPASS: lseek(tfile2, 2, SEEK_SET) wrote correct data abijkfg

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mallopt01 stime=1614120171
cmdline="mallopt01"
contacts=""
analysis=exit
<<<test_output>>>
mallopt01    1  TPASS  :  mallinfo() succeeded
mallopt01    2  TPASS  :  mallopt(M_MXFAST, 160) succeeded
mallopt01    3  TPASS  :  mallopt(M_NLBLKS, 50) succeeded
mallopt01    4  TPASS  :  malloc(1024) succeeded
mallopt01    5  TPASS  :  mallopt(M_MXFAST, 0) succeeded
mallopt01    6  TPASS  :  malloc(1024) succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=migrate_pages03 stime=1614120171
cmdline="migrate_pages03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
migrate_pages03.c:60: TCONF: requires NUMA with at least 2 node

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mlockall02 stime=1614120171
cmdline="mlockall02"
contacts=""
analysis=exit
<<<test_output>>>
mlockall02    1  TPASS  :  expected failure - errno = 12 : Cannot allocate memory
mlockall02    2  TPASS  :  expected failure - errno = 1 : Operation not permitted
mlockall02    3  TPASS  :  expected failure - errno = 22 : Invalid argument
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mkdir02 stime=1614120171
cmdline="mkdir02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
mkdir02.c:55: TPASS: New dir inherited GID and S_ISGID

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mkdir04 stime=1614120171
cmdline="mkdir04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
mkdir04.c:37: TPASS: mkdir() failed expectedly: EACCES (13)

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=mknodat01 stime=1614120171
cmdline="mknodat01"
contacts=""
analysis=exit
<<<test_output>>>
mknodat01    1  TPASS  :  mknodat() returned 0: TEST_ERRNO=SUCCESS(0): Success
mknodat01    2  TPASS  :  mknodat() returned 0: TEST_ERRNO=SUCCESS(0): Success
mknodat01    3  TPASS  :  mknodat() returned -1: TEST_ERRNO=ENOTDIR(20): Not a directory
mknodat01    4  TPASS  :  mknodat() returned -1: TEST_ERRNO=EBADF(9): Bad file descriptor
mknodat01    5  TPASS  :  mknodat() returned 0: TEST_ERRNO=SUCCESS(0): Success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mlock02 stime=1614120171
cmdline="mlock02"
contacts=""
analysis=exit
<<<test_output>>>
mlock02     1  TPASS  :  mlock failed as expected: TEST_ERRNO=ENOMEM(12): Cannot allocate memory
mlock02     2  TPASS  :  mlock failed as expected: TEST_ERRNO=ENOMEM(12): Cannot allocate memory
mlock02     3  TPASS  :  mlock failed as expected: TEST_ERRNO=EPERM(1): Operation not permitted
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mlock04 stime=1614120171
cmdline="mlock04"
contacts=""
analysis=exit
<<<test_output>>>
mlock04     0  TINFO  :  locked 40960 bytes from 0x7f32cb3fc000
mlock04     1  TPASS  :  test succeeded.
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=qmm01 stime=1614120171
cmdline="mmap001 -m 1"
contacts=""
analysis=exit
<<<test_output>>>
mmap001     0  TINFO  :  mmap()ing file of 1 pages or 4096 bytes
mmap001     1  TPASS  :  mmap() completed successfully.
mmap001     0  TINFO  :  touching mmaped memory
mmap001     2  TPASS  :  we're still here, mmaped area must be good
mmap001     3  TPASS  :  synchronizing mmapped page passed
mmap001     4  TPASS  :  munmapping testfile.3348 successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mmap04 stime=1614120171
cmdline="mmap04"
contacts=""
analysis=exit
<<<test_output>>>
mmap04      1  TPASS  :  Functionality of mmap() successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mmap05 stime=1614120171
cmdline="mmap05"
contacts=""
analysis=exit
<<<test_output>>>
mmap05      1  TPASS  :  Got SIGSEGV as expected
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mmap12 stime=1614120171
cmdline="mmap12"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
mmap12.c:90: TINFO: All pages are present
mmap12.c:114: TPASS: File mapped properly

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mmap13 stime=1614120171
cmdline="mmap13"
contacts=""
analysis=exit
<<<test_output>>>
mmap13      1  TPASS  :  Got SIGBUS as expected
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=modify_ldt03 stime=1614120171
cmdline="modify_ldt03"
contacts=""
analysis=exit
<<<test_output>>>
modify_ldt03    1  TCONF  :  modify_ldt03.c:94: modify_ldt is available but not tested on the platform than __i386__
modify_ldt03    2  TCONF  :  modify_ldt03.c:94: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=move_pages12 stime=1614120171
cmdline="move_pages12"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
move_pages_support.c:407: TCONF: at least 2 allowed NUMA nodes are required

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=mprotect04 stime=1614120171
cmdline="mprotect04"
contacts=""
analysis=exit
<<<test_output>>>
mprotect04    1  TPASS  :  test PROT_NONE for mprotect success
mprotect04    0  TINFO  :  exec_func: 0x55eca8ab1cc0, page_to_copy: 0x55eca8ab1000
mprotect04    2  TPASS  :  test PROT_EXEC for mprotect success
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=mremap05 stime=1614120171
cmdline="mremap05"
contacts=""
analysis=exit
<<<test_output>>>
mremap05    1  TPASS  :  MREMAP_FIXED requires MREMAP_MAYMOVE
mremap05    2  TPASS  :  new_addr has to be page aligned
mremap05    3  TPASS  :  old/new area must not overlap
mremap05    4  TPASS  :  mremap #1
mremap05    5  TPASS  :  mremap #1 value OK
mremap05    6  TPASS  :  mremap #2
mremap05    7  TPASS  :  mremap #2 value OK
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msgctl03 stime=1614120171
cmdline="msgctl03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msgctl03.c:30: TPASS: msgctl(IPC_RMID)
msgctl03.c:34: TPASS: msgctl(IPC_STAT): EINVAL (22)

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msgrcv06 stime=1614120171
cmdline="msgrcv06"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msgrcv06.c:33: TPASS: msgrcv() failed as expected: EIDRM (43)

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msync02 stime=1614120171
cmdline="msync02"
contacts=""
analysis=exit
<<<test_output>>>
msync02     1  TPASS  :  Functionality of msync successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=msync04 stime=1614120171
cmdline="msync04"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:859: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
tst_test.c:870: TINFO: Trying FUSE...
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
msync04.c:72: TPASS: msync() working correctly

Summary:
passed   7
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=7 cstime=106
<<<test_end>>>
<<<test_start>>>
tag=nice01 stime=1614120175
cmdline="nice01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
nice01.c:48: TPASS: nice(-12) passed

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=open01A stime=1614120175
cmdline="symlink01 -T open01"
contacts=""
analysis=exit
<<<test_output>>>
open01      1  TPASS  :  open(2) with (O_CREAT | O_RDWR) to create object file through symbolic link file and all writes, reads, and lseeks are ok
open01      2  TPASS  :  open(2) with O_RDWR of existing  object file through symbolic link file and all writes, reads, and lseeks are ok
open01      3  TPASS  :  open(2) with (O_CREAT | O_EXCL) error  is caught when creating object file through symbolic link file
open01      4  TPASS  :  open(2) error with O_RDWR is caught when processing symbolic link file which points at no object file
open01      5  TPASS  :  Nested symbolic link access condition caught.  ELOOP is returned
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=madvise10 stime=1614120175
cmdline="madvise10"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
madvise10.c:134: TINFO: MADV_WIPEONFORK zeroes memory in child
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x0)
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x12)
madvise10.c:89: TPASS: In PID 3468, Matched expected pattern
madvise10.c:134: TINFO: MADV_WIPEONFORK with zero length does nothing
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 0, 0x0)
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 0, 0x12)
madvise10.c:89: TPASS: In PID 3469, Matched expected pattern
madvise10.c:134: TINFO: MADV_WIPEONFORK zeroes memory in grand-child
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x0)
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x12)
madvise10.c:89: TPASS: In PID 3471, Matched expected pattern
madvise10.c:134: TINFO: MADV_KEEPONFORK will undo MADV_WIPEONFORK
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x12)
madvise10.c:108: TPASS: madvise(0x7f4cdd245000, 16384, 0x13)
madvise10.c:89: TPASS: In PID 3472, Matched expected pattern

Summary:
passed   12
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pause01 stime=1614120175
cmdline="pause01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
pause01.c:24: TPASS: pause() interrupted with EINTR

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=personality01 stime=1614120175
cmdline="personality01"
contacts=""
analysis=exit
<<<test_output>>>
personality01    1  TPASS  :  personality(PER_LINUX)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_LINUX_32BIT)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_SVR4)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_SVR3)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_SCOSVR3)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_OSR5)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_WYSEV386)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_ISCR4)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_BSD)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_XENIX)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_LINUX32)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_IRIX32)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_IRIXN32)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_IRIX64)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_RISCOS)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_SOLARIS)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_UW7)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_OSF4)
personality01    0  TINFO  :  Child process returned TPASS
personality01    1  TPASS  :  personality(PER_HPUX)
personality01    0  TINFO  :  Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pipe01 stime=1614120175
cmdline="pipe01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
pipe01.c:48: TPASS: pipe() functionality is correct

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=poll01 stime=1614120175
cmdline="poll01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
poll01.c:42: TPASS: poll() POLLOUT
poll01.c:69: TPASS: poll() POLLIN

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pread03_64 stime=1614120175
cmdline="pread03_64"
contacts=""
analysis=exit
<<<test_output>>>
pread03     1  TPASS  :  pread() fails with expected error EISDIR errno:21
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=preadv202_64 stime=1614120175
cmdline="preadv202_64"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
preadv202.c:82: TPASS: preadv2() failed as expected: EINVAL (22)
preadv202.c:82: TPASS: preadv2() failed as expected: EINVAL (22)
preadv202.c:82: TPASS: preadv2() failed as expected: EOPNOTSUPP (95)
preadv202.c:82: TPASS: preadv2() failed as expected: EFAULT (14)
preadv202.c:82: TPASS: preadv2() failed as expected: EBADF (9)
preadv202.c:82: TPASS: preadv2() failed as expected: EBADF (9)
preadv202.c:82: TPASS: preadv2() failed as expected: EISDIR (21)
preadv202.c:82: TPASS: preadv2() failed as expected: ESPIPE (29)

Summary:
passed   8
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=process_vm_writev02 stime=1614120175
cmdline="process_vm_writev02"
contacts=""
analysis=exit
<<<test_output>>>
process_vm_writev02    0  TINFO  :  child 2: write to the same memory location.
process_vm_writev02    0  TINFO  :  child 0: memory allocated.
process_vm_writev02    1  TPASS  :  child 0: all bytes are expected.
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=pselect03 stime=1614120175
cmdline="pselect03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
pselect03.c:31: TPASS: pselect() succeeded retval=0

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=ptrace07 stime=1614120175
cmdline="ptrace07"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
ptrace07.c:138: TINFO: PTRACE_SETREGSET with reserved bits failed with EINVAL
ptrace07.c:161: TINFO: test child 3510 exited, retcode: 0
ptrace07.c:174: TPASS: wasn't able to set invalid FPU state

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=170 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=quotactl07 stime=1614120176
cmdline="quotactl07"
contacts=""
analysis=exit
<<<test_output>>>
tst_kconfig.c:63: TINFO: Parsing kernel config '/proc/config.gz'
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
quotactl07.c:32: TPASS: Q_XQUOTARM has quota type check

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=realpath01 stime=1614120176
cmdline="realpath01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
realpath01.c:35: TPASS: bug not reproduced

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=recvmsg03 stime=1614120176
cmdline="recvmsg03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
recvmsg03.c:38: TCONF: rds was not supported

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=rename03 stime=1614120176
cmdline="rename03"
contacts=""
analysis=exit
<<<test_output>>>
rename03    1  TPASS  :  functionality is correct for renaming a file
rename03    2  TPASS  :  functionality is correct for renaming a directory
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=rename11 stime=1614120177
cmdline="rename11"
contacts=""
analysis=exit
<<<test_output>>>
mke2fs 1.44.5 (15-Dec-2018)
rename11    0  TINFO  :  Found free device 0 '/dev/loop0'
rename11    0  TINFO  :  Formatting /dev/loop0 with ext2 opts='' extra opts=''
rename11    0  TINFO  :  Failed reach the subdirs limit on F2FS filesystem
rename11    1  TPASS  :  failed as expected: TEST_ERRNO=ELOOP(40): Too many levels of symbolic links
rename11    2  TPASS  :  failed as expected: TEST_ERRNO=EROFS(30): Read-only file system
rename11    3  TCONF  :  rename11.c:167: EMLINK test is not appropriate
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=7 cstime=145
<<<test_end>>>
<<<test_start>>>
tag=request_key04 stime=1614120178
cmdline="request_key04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
request_key04.c:66: TPASS: request_key() failed with EACCES as expected

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sched_get_priority_min02 stime=1614120178
cmdline="sched_get_priority_min02"
contacts=""
analysis=exit
<<<test_output>>>
sched_get_priority_min02    1  TPASS  :  Test Passed, Got EINVAL
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sched_getparam03 stime=1614120178
cmdline="sched_getparam03"
contacts=""
analysis=exit
<<<test_output>>>
sched_getparam03    1  TPASS  :  expected failure; Got ESRCH
sched_getparam03    2  TPASS  :  expected failure; Got EINVAL
sched_getparam03    3  TPASS  :  expected failure; Got EINVAL
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sched_setparam05 stime=1614120178
cmdline="sched_setparam05"
contacts=""
analysis=exit
<<<test_output>>>
sched_setparam05    1  TPASS  :  Test passed, Got EPERM
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sched_setscheduler01 stime=1614120178
cmdline="sched_setscheduler01"
contacts=""
analysis=exit
<<<test_output>>>
sched_setscheduler01    1  TPASS  :  expected failure - errno = 3 : No such process
sched_setscheduler01    2  TPASS  :  expected failure - errno = 22 : Invalid argument
sched_setscheduler01    3  TPASS  :  expected failure - errno = 14 : Bad address
sched_setscheduler01    4  TPASS  :  expected failure - errno = 22 : Invalid argument
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=select04 stime=1614120178
cmdline="select04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
select_var.h:109: TINFO: Testing libc select()
select04.c:58: TPASS: No data to read: select() cleared the fd set
select04.c:58: TPASS: No space to write: select() cleared the fd set
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
select_var.h:112: TINFO: Testing SYS_select syscall
select04.c:58: TPASS: No data to read: select() cleared the fd set
select04.c:58: TPASS: No space to write: select() cleared the fd set
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
select_var.h:115: TINFO: Testing SYS_pselect6 syscall
select04.c:58: TPASS: No data to read: select() cleared the fd set
select04.c:58: TPASS: No space to write: select() cleared the fd set
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
select_var.h:118: TINFO: Testing SYS_pselect6 time64 syscall
select_var.h:83: TCONF: __NR_pselect6 time64 variant not supported
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
select_var.h:121: TINFO: Testing SYS__newselect syscall
select_var.h:89: TCONF: syscall(-1) __NR__newselect not supported

Summary:
passed   6
failed   0
broken   0
skipped  2
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=2
<<<test_end>>>
<<<test_start>>>
tag=semctl02 stime=1614120178
cmdline="semctl02"
contacts=""
analysis=exit
<<<test_output>>>
semctl02    1  TPASS  :  expected failure - errno = 13 : Permission denied
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=semop01 stime=1614120178
cmdline="semop01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
semop01.c:71: TINFO: Testing variant: semop: syscall
semop01.c:58: TPASS: semaphore values are correct
semop01.c:58: TPASS: semaphore values are correct
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
semop01.c:71: TINFO: Testing variant: semtimedop: syscall with old kernel spec
semop01.c:58: TPASS: semaphore values are correct
semop01.c:58: TPASS: semaphore values are correct

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=sendfile05_64 stime=1614120178
cmdline="sendfile05_64"
contacts=""
analysis=exit
<<<test_output>>>
sendfile05_64    1  TPASS  :  sendfile() returned 22 : Invalid argument
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sendfile06 stime=1614120178
cmdline="sendfile06"
contacts=""
analysis=exit
<<<test_output>>>
sendfile06    1  TPASS  :  functionality of sendfile() is correct
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sendmmsg02 stime=1614120178
cmdline="sendmmsg02"
contacts=""
analysis=exit
<<<test_output>>>
tst_buffers.c:55: TINFO: Test is using guarded buffers
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
sendmmsg02.c:56: TINFO: Testing variant: vDSO or syscall with libc spec
sendmmsg02.c:49: TPASS: sendmmsg() bad file descriptor: EBADF (9)
sendmmsg02.c:49: TPASS: sendmmsg() invalid msgvec address: EFAULT (14)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
sendmmsg02.c:56: TINFO: Testing variant: syscall with old kernel spec
sendmmsg02.c:49: TPASS: sendmmsg() bad file descriptor: EBADF (9)
sendmmsg02.c:49: TPASS: sendmmsg() invalid msgvec address: EFAULT (14)

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sendto01 stime=1614120178
cmdline="sendto01"
contacts=""
analysis=exit
<<<test_output>>>
sendto01    1  TPASS  :  bad file descriptor successful
sendto01    2  TPASS  :  invalid socket successful
sendto01    3  TPASS  :  invalid send buffer successful
sendto01    4  TPASS  :  connected TCP successful
sendto01    5  TPASS  :  not connected TCP successful
sendto01    6  TPASS  :  invalid to buffer length successful
sendto01    7  TPASS  :  invalid to buffer successful
sendto01    8  TPASS  :  UDP message too big successful
sendto01    9  TPASS  :  local endpoint shutdown successful
sendto01   10  TPASS  :  invalid flags set successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=set_mempolicy04 stime=1614120178
cmdline="set_mempolicy04"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on btrfs
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on vfat
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes
tst_test.c:1329: TINFO: Testing on ntfs
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
tst_numa.c:191: TINFO: Found 1 NUMA memory nodes
set_mempolicy04.c:48: TCONF: Test requires at least two NUMA memory nodes

Summary:
passed   0
failed   0
broken   0
skipped  7
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=32 corefile=no
cutime=1 cstime=3
<<<test_end>>>
<<<test_start>>>
tag=setdomainname03 stime=1614120179
cmdline="setdomainname03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setdomainname.h:36: TINFO: Testing libc setdomainname()
setdomainname03.c:32: TPASS: expected failure: EPERM (1)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setdomainname.h:39: TINFO: Testing __NR_setdomainname syscall
setdomainname03.c:32: TPASS: expected failure: EPERM (1)

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setfsuid03 stime=1614120179
cmdline="setfsuid03"
contacts=""
analysis=exit
<<<test_output>>>
setfsuid03    1  TPASS  :  setfsuid() returned expected value : 65534
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setgid01 stime=1614120179
cmdline="setgid01"
contacts=""
analysis=exit
<<<test_output>>>
setgid01    1  TPASS  :  setgid(0) returned 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setegid01 stime=1614120179
cmdline="setegid01"
contacts=""
analysis=exit
<<<test_output>>>
setegid01    0  TINFO  :  getresgid reports rgid 0, egid 0, sgid 0
setegid01    0  TINFO  :  calling setegid(nobody_gid 65534)
setegid01    0  TINFO  :  getresgid reports rgid 0, egid 65534, sgid 0
setegid01    1  TPASS  :  setegid() passed functional test
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setgroups01 stime=1614120179
cmdline="setgroups01"
contacts=""
analysis=exit
<<<test_output>>>
setgroups01    1  TPASS  :  setgroups(65536, list) returned 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setgroups02 stime=1614120179
cmdline="setgroups02"
contacts=""
analysis=exit
<<<test_output>>>
setgroups02    1  TPASS  :  Functionality of setgroups(1, groups_list) successful
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setgroups04 stime=1614120179
cmdline="setgroups04"
contacts=""
analysis=exit
<<<test_output>>>
setgroups04    1  TPASS  :  setgroups() fails with expected error EFAULT errno:14
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=sethostname02 stime=1614120179
cmdline="sethostname02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname.h:36: TINFO: Testing libc sethostname()
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing len == -1
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EINVAL (22)
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing len > allowed maximum
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EINVAL (22)
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing name == NULL
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EFAULT (14)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname.h:39: TINFO: Testing __NR_sethostname syscall
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing len == -1
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EINVAL (22)
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing len > allowed maximum
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EINVAL (22)
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:32: TINFO: testing name == NULL
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/sethostname/../setdomainname/setdomainname02.c:44: TPASS: expected failure: EFAULT (14)

Summary:
passed   6
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setpgid02 stime=1614120179
cmdline="setpgid02"
contacts=""
analysis=exit
<<<test_output>>>
setpgid02    1  TPASS  :  expected failure - errno = 22 : Invalid argument
setpgid02    2  TPASS  :  expected failure - errno = 3 : No such process
setpgid02    3  TPASS  :  expected failure - errno = 1 : Operation not permitted
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setregid03 stime=1614120179
cmdline="setregid03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setregid03.c:61: TINFO: getgrnam(nobody) failed - try fallback nogroup
setregid03.c:95: TPASS: setregid(1, 2) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(-1, 1) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(-1, 2) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(2, -1) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(-1, -1) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(-1, 2) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(2, -1) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:95: TPASS: setregid(2, 2) succeeded as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:105: TPASS: setregid(1, -1) failed as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:105: TPASS: setregid(-1, 1) failed as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected
setregid03.c:105: TPASS: setregid(1, 1) failed as expected
setregid03.c:121: TPASS: real or effective gid was modified as expected

Summary:
passed   22
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setresgid01_16 stime=1614120179
cmdline="setresgid01_16"
contacts=""
analysis=exit
<<<test_output>>>
setresgid01_16    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/setresgid/../utils/compat_16.h:146: 16-bit version of setresgid() is not supported on your platform
setresgid01_16    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/setresgid/../utils/compat_16.h:146: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setresuid01_16 stime=1614120179
cmdline="setresuid01_16"
contacts=""
analysis=exit
<<<test_output>>>
setresuid01_16    1  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/setresuid/../utils/compat_16.h:136: 16-bit version of setresuid() is not supported on your platform
setresuid01_16    2  TCONF  :  /tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/setresuid/../utils/compat_16.h:136: Remaining cases not appropriate for configuration
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setreuid05 stime=1614120179
cmdline="setreuid05"
contacts=""
analysis=exit
<<<test_output>>>
setreuid05    1  TPASS  :  setreuid(65534, 0) succeeded as expected.
setreuid05    2  TPASS  :  setreuid(-1, 65534) succeeded as expected.
setreuid05    3  TPASS  :  setreuid(-1, 0) succeeded as expected.
setreuid05    4  TPASS  :  setreuid(1, -1) succeeded as expected.
setreuid05    5  TPASS  :  setreuid(-1, 2) succeeded as expected.
setreuid05    6  TPASS  :  setreuid(-1, 0) succeeded as expected.
setreuid05    7  TPASS  :  setreuid(-1, 65534) succeeded as expected.
setreuid05    8  TPASS  :  setreuid(-1, 1) succeeded as expected.
setreuid05    9  TPASS  :  setreuid(-1, 2) succeeded as expected.
setreuid05   10  TPASS  :  setreuid(2, 1) succeeded as expected.
setreuid05   11  TPASS  :  setreuid(-1, 2) succeeded as expected.
setreuid05   12  TPASS  :  setreuid(-1, 1) succeeded as expected.
setreuid05   13  TPASS  :  setreuid(1, -1) succeeded as expected.
setreuid05   14  TPASS  :  setreuid(-1, 2) succeeded as expected.
setreuid05    0  TINFO  :  Child process returned TPASS
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setrlimit03 stime=1614120179
cmdline="setrlimit03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setrlimit03.c:55: TPASS: setrlimit() failed as expected: EPERM (1)
setrlimit03.c:55: TPASS: setrlimit() failed as expected: EINVAL (22)

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=setrlimit05 stime=1614120179
cmdline="setrlimit05"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setrlimit05.c:38: TPASS: setrlimit() failed as expected: EFAULT (14)

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setrlimit06 stime=1614120179
cmdline="setrlimit06"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setrlimit06.c:86: TPASS: Got SIGXCPU then SIGKILL after reaching both limit

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=200 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setsockopt04 stime=1614120181
cmdline="setsockopt04"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
setsockopt04.c:39: TINFO: Try to set send buffer size to: 4294967040
setsockopt04.c:40: TINFO: Send buffer size was set to: 4608
setsockopt04.c:45: TPASS: Was unable to set negative send buffer size!

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=setuid03_16 stime=1614120181
cmdline="setuid03_16"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
/tmp/lkp/ltp/src/ltp/testcases/kernel/syscalls/setuid/../utils/compat_tst_16.h:84: TCONF: 16-bit version of setuid() is not supported on your platform

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=shmctl03 stime=1614120181
cmdline="shmctl03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
shmctl03.c:34: TPASS: shmmin = 1
shmctl03.c:36: TPASS: /proc/sys/kernel/shmmax = 18446744073692774399
shmctl03.c:37: TPASS: /proc/sys/kernel/shmmni = 4096
shmctl03.c:38: TPASS: /proc/sys/kernel/shmall = 18446744073692774399

Summary:
passed   4
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=signal06 stime=1614120181
cmdline="signal06"
contacts=""
analysis=exit
<<<test_output>>>
signal06    0  TINFO  :  loop = 30000
signal06    1  TPASS  :  signal06 call succeeded
signal06    0  TINFO  :  loop = 30000
signal06    2  TPASS  :  signal06 call succeeded
signal06    0  TINFO  :  loop = 30000
signal06    3  TPASS  :  signal06 call succeeded
signal06    0  TINFO  :  loop = 30000
signal06    4  TPASS  :  signal06 call succeeded
signal06    0  TINFO  :  loop = 30000
signal06    5  TPASS  :  signal06 call succeeded
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=33 cstime=109
<<<test_end>>>
<<<test_start>>>
tag=sigtimedwait01 stime=1614120182
cmdline="sigtimedwait01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
sigwait.c:27: TPASS: Wait interrupted by expected signal
sigwait.c:88: TPASS: struct siginfo is correct
sigwait.c:148: TPASS: struct siginfo is correct
sigwait.c:160: TPASS: sigwaitinfo restored the original mask
sigwait.c:113: TPASS: Wait interrupted by expected signal
sigwait.c:259: TPASS: Wait interrupted by expected signal
sigwait.c:268: TPASS: sigwaitinfo restored the original mask
sigwait.c:302: TPASS: Fault occurred while accessing the buffers
sigwait.c:344: TPASS: Child exited with expected code
sigwait.c:367: TPASS: Fault occurred while accessing the buffers
sigwait.c:57: TPASS: Wait interrupted by timeout

Summary:
passed   11
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=sigwait01 stime=1614120183
cmdline="sigwait01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
sigwait.c:113: TPASS: Wait interrupted by expected signal
sigwait.c:259: TPASS: Wait interrupted by expected signal
sigwait.c:268: TPASS: sigwaitinfo restored the original mask

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=socket01 stime=1614120183
cmdline="socket01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
socket01.c:66: TPASS: invalid domain successful
socket01.c:66: TPASS: invalid type successful
socket01.c:66: TPASS: UNIX domain dgram successful
socket01.c:66: TPASS: raw open as non-root successful
socket01.c:66: TPASS: UDP socket successful
socket01.c:66: TPASS: UDP stream successful
socket01.c:66: TPASS: TCP dgram successful
socket01.c:66: TPASS: TCP socket successful
socket01.c:66: TPASS: ICMP stream successful

Summary:
passed   9
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=stat01 stime=1614120183
cmdline="stat01"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
stat01.c:75: TPASS: stat(test_fileread)
stat01.c:75: TPASS: stat(test_filenoread)

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=statfs03_64 stime=1614120183
cmdline="statfs03_64"
contacts=""
analysis=exit
<<<test_output>>>
statfs03    1  TPASS  :  expected failure - errno = 13 : Permission denied
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=syslog06 stime=1614120183
cmdline="syslog06"
contacts=""
analysis=exit
<<<test_output>>>
syslog06    0  TINFO  :   Test the logging option: LOG_NDELAY
syslog06    0  TINFO  :   o Do openlog() without LOG_NDELAY option.
syslog06    0  TINFO  :   o open a file and check the returned file descriptor
syslog06    0  TINFO  :     It should be 3.
syslog06    0  TINFO  :   o Now do openlog() with LOG_NDELAY option.
syslog06    0  TINFO  :   o open a file and check the returned file descriptor.
syslog06    0  TINFO  :     It should be greater than 3.
syslog06    0  TINFO  :  syslog: Testing the log option: LOG_NDELAY...
syslog06    0  TINFO  :  restarting syslog daemon
syslog06    0  TINFO  :  restarting syslog daemon
<<<execution_status>>>
initiation_status="ok"
duration=4 termination_type=exited termination_id=0 corefile=no
cutime=2 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=timerfd02 stime=1614120187
cmdline="timerfd02"
contacts=""
analysis=exit
<<<test_output>>>
timerfd02    1  TPASS  :  timerfd_create(TFD_CLOEXEC) Passed
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=timer_create02 stime=1614120187
cmdline="timer_create02"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
timer_create02.c:73: TPASS: invalid sigevent struct failed as expected: EFAULT (14)
timer_create02.c:73: TPASS: invalid timer ID failed as expected: EFAULT (14)
timer_create02.c:73: TPASS: invalid clock failed as expected: EINVAL (22)
timer_create02.c:73: TPASS: wrong sigev_notify failed as expected: EINVAL (22)
timer_create02.c:73: TPASS: wrong sigev_signo failed as expected: EINVAL (22)

Summary:
passed   5
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=truncate02_64 stime=1614120187
cmdline="truncate02_64"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
truncate02.c:90: TPASS: truncate(testfile, 256) succeeded
truncate02.c:90: TPASS: truncate(testfile, 512) succeeded

Summary:
passed   2
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=unshare01 stime=1614120187
cmdline="unshare01"
contacts=""
analysis=exit
<<<test_output>>>
unshare with CLONE_FILES call succeeded
unshare with CLONE_FS call succeeded
unshare call with CLONE_NEWNS succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=umount02 stime=1614120187
cmdline="umount02"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
umount02.c:58: TPASS: umount() fails as expected: Already mounted/busy: EBUSY (16)
umount02.c:58: TPASS: umount() fails as expected: Invalid address: EFAULT (14)
umount02.c:58: TPASS: umount() fails as expected: Directory not found: ENOENT (2)
umount02.c:58: TPASS: umount() fails as expected: Invalid  device: EINVAL (22)
umount02.c:58: TPASS: umount() fails as expected: Pathname too long: ENAMETOOLONG (36)

Summary:
passed   5
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=5
<<<test_end>>>
<<<test_start>>>
tag=utime06 stime=1614120188
cmdline="utime06"
contacts=""
analysis=exit
<<<test_output>>>
mke2fs 1.44.5 (15-Dec-2018)
utime06     0  TINFO  :  Found free device 0 '/dev/loop0'
utime06     0  TINFO  :  Formatting /dev/loop0 with ext2 opts='' extra opts=''
utime06     1  TPASS  :  utime failed as expected: TEST_ERRNO=EACCES(13): Permission denied
utime06     2  TPASS  :  utime failed as expected: TEST_ERRNO=ENOENT(2): No such file or directory
utime06     3  TPASS  :  utime failed as expected: TEST_ERRNO=EPERM(1): Operation not permitted
utime06     4  TPASS  :  utime failed as expected: TEST_ERRNO=EROFS(30): Read-only file system
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=3
<<<test_end>>>
<<<test_start>>>
tag=wait401 stime=1614120188
cmdline="wait401"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
wait401.c:42: TPASS: waitpid() returned correct pid 3768
wait401.c:51: TPASS: WIFEXITED() is set in status
wait401.c:56: TPASS: WEXITSTATUS() == 0

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=waitpid10 stime=1614120188
cmdline="waitpid10"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
waitpid10.c:62: TPASS: Test PASSED

Summary:
passed   1
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=2 termination_type=exited termination_id=0 corefile=no
cutime=1 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=writev06 stime=1614120190
cmdline="writev06"
contacts=""
analysis=exit
<<<test_output>>>
writev06    0  TINFO  :  Enter block 1
writev06    0  TINFO  :  writev returned 2 as expected
writev06    0  TINFO  :  block 1 PASSED
writev06    0  TINFO  :  Exit block 1
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=perf_event_open01 stime=1614120190
cmdline="perf_event_open01"
contacts=""
analysis=exit
<<<test_output>>>
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 300000047
perf_event_open01    1  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_HW_INSTRUCTIONS succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 21
perf_event_open01    2  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_HW_CACHE_REFERENCES succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 0
perf_event_open01    3  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_HW_CACHE_MISSES succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 100000038
perf_event_open01    4  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_HW_BRANCH_INSTRUCTIONS succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 3
perf_event_open01    5  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_HW_BRANCH_MISSES succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 32646654
perf_event_open01    6  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_SW_CPU_CLOCK succeeded
perf_event_open01    0  TINFO  :  read event counter succeeded, value: 32077670
perf_event_open01    7  TPASS  :  test PERF_TYPE_HARDWARE: PERF_COUNT_SW_TASK_CLOCK succeeded
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=23 cstime=1
<<<test_end>>>
<<<test_start>>>
tag=futex_wake03 stime=1614120190
cmdline="futex_wake03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
futex_wake03.c:97: TINFO: Testing variant: syscall with old kernel spec
futex_wake03.c:61: TPASS: futex_wake() woken up 1 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 2 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 3 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 4 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 5 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 6 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 7 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 8 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 9 childs
futex_wake03.c:61: TPASS: futex_wake() woken up 10 childs
futex_wake03.c:89: TPASS: futex_wake() woken up 0 children

Summary:
passed   11
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=memfd_create03 stime=1614120190
cmdline="memfd_create03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
memfd_create03.c:180: TINFO: --TESTING WRITE CALL IN HUGEPAGES--
memfd_create03.c:185: TINFO: memfd_create() succeeded
memfd_create03.c:81: TPASS: write(4, "LTP", 3) failed as expected

memfd_create03.c:180: TINFO: --TESTING PAGE SIZE OF CREATED FILE--
memfd_create03.c:185: TINFO: memfd_create() succeeded
memfd_create03.c:54: TINFO: mmap((nil), 2097152, 2, 2, 4, 0) succeeded
memfd_create03.c:103: TINFO: munmap(0x7ff328c00000, 512kB) failed as expected
memfd_create03.c:103: TINFO: munmap(0x7ff328c00000, 1024kB) failed as expected
memfd_create03.c:103: TINFO: munmap(0x7ff328c00000, 1536kB) failed as expected
memfd_create03.c:121: TPASS: munmap() fails for page sizes less than 2048kB

memfd_create03.c:180: TINFO: --TESTING HUGEPAGE ALLOCATION LIMIT--
memfd_create03.c:185: TINFO: memfd_create() succeeded
memfd_create03.c:54: TINFO: mmap((nil), 2097152, 2, 2, 4, 0) succeeded
memfd_create03.c:140: TINFO: memfd_create() succeeded
memfd_create03.c:147: TPASS: mmap((nil), 2097152, 0, 2, 5, 0) failed as expected

Summary:
passed   3
failed   0
broken   0
skipped  0
warnings 0
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=0 corefile=no
cutime=0 cstime=0
<<<test_end>>>
<<<test_start>>>
tag=copy_file_range01 stime=1614120190
cmdline="copy_file_range01"
contacts=""
analysis=exit
<<<test_output>>>
tst_device.c:89: TINFO: Found free device 0 '/dev/loop0'
tst_supported_fs_types.c:60: TINFO: Kernel supports ext2
tst_supported_fs_types.c:44: TINFO: mkfs.ext2 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext3
tst_supported_fs_types.c:44: TINFO: mkfs.ext3 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports ext4
tst_supported_fs_types.c:44: TINFO: mkfs.ext4 does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports xfs
tst_supported_fs_types.c:44: TINFO: mkfs.xfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports btrfs
tst_supported_fs_types.c:44: TINFO: mkfs.btrfs does exist
tst_supported_fs_types.c:60: TINFO: Kernel supports vfat
tst_supported_fs_types.c:44: TINFO: mkfs.vfat does exist
tst_supported_fs_types.c:83: TINFO: Filesystem exfat is not supported
tst_supported_fs_types.c:92: TINFO: FUSE does support ntfs
tst_supported_fs_types.c:44: TINFO: mkfs.ntfs does exist
tst_test.c:1329: TINFO: Testing on ext2
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
copy_file_range.h:36: TINFO: Testing libc copy_file_range()
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: non cross-device copy_file_range failed 144 of 144 copy jobs.
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: cross-device copy_file_range failed 144 of 144 copy jobs.
tst_test.c:1329: TINFO: Testing on ext3
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
copy_file_range.h:36: TINFO: Testing libc copy_file_range()
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: non cross-device copy_file_range failed 144 of 144 copy jobs.
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: cross-device copy_file_range failed 144 of 144 copy jobs.
tst_test.c:1329: TINFO: Testing on ext4
tst_test.c:859: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.44.5 (15-Dec-2018)
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
copy_file_range.h:36: TINFO: Testing libc copy_file_range()
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: non cross-device copy_file_range failed 144 of 144 copy jobs.
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:211: TFAIL: cross-device copy_file_range failed 144 of 144 copy jobs.
tst_test.c:1329: TINFO: Testing on xfs
tst_test.c:859: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
tst_test.c:1263: TINFO: Timeout per run is 0h 25m 00s
copy_file_range.h:36: TINFO: Testing libc copy_file_range()
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: copy_file_range() failed: EOPNOTSUPP (95)
copy_file_range01.c:133: TFAIL: c