Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

[Daan De Meyer]

Hi Amir,

I tested the series on top of f6cde11eb46e and cherry-picked these
selftests:

https://github.com/daandemeyer/vfs/commit/0b0e47d408311fe2b4a3e1711656f836b56e10f4

All four tests failed.

The accounting test reports two reads and writes, and 128 KiB
accounted in each direction, for one 64 KiB copy. The outer and
recursive backing-file VFS calls both account the operation.

The credential test fails with EPERM. The explicit source check uses
the source mount credentials, but the recursive VFS call checks the
real source again while the destination mount credentials are active.

The permission-order test times out because the real source
FAN_ACCESS_PERM event happens after the destination inode has been
locked. The process handling the event cannot update the destination
while the copy is waiting for its response.

Finally, denying that permission event still clears the destination's
setuid and setgid bits. ovl_copyfile() removes them before checking
permission on the real source.

It looks like the root cause is that OverlayFS-to-OverlayFS is
classified as FS_COPY_SAME_FS before the FOP_CROSS_FS_COPY checks.
That leaves it on the existing recursive VFS path, so these issues
remain even with the series applied.

My (admittedly much larger) patch set does pass all of these selftests
by moving most of
the authorization checks out of overlayfs and into vfs and can be found here:
https://github.com/linux-fsdevel/vfs/compare/vfs.base...daandemeyer:vfs:push-zolnnszvmkry
for those interested in taking a look. Happy to post it directly to
the list as an RFC if that's
preferred over a github link. That patch set also lays a foundation
for cross sb copy_file_range()
but I opted to not post those patches yet so we can figure out how we
want to deal with the above
issues first.

Cheers,
Daan


On Thu, 23 Jul 2026 at 13:48, Amir Goldstein <amir73il@gmail.com> wrote:
>
> Hi all,
>
> Daan De Meyer requested a way to do copy_file_range() from overlayfs
> to/from another fs, where if that fs is the base fs of overlayfs layer
> the copy could be an efficient clone.
>
> TBH, he also requested support also for cross-fs clone_file_range(),
> but I am not happy about providing that.
>
> copy_file_range() already supports cross-sb efficient copy (e.g. with
> NFS/SMB server-side copy).
>
> The current limitation of staying on the same fstype is mainly an
> internal technical limitation (choosing the right f_op), which is
> something that this RFC is trying to address.
>
> The overlayfs implementation itself is pretty trivial.
>
> Thanks,
> Amir.
>
>
> Amir Goldstein (5):
>   fs: clarify cross-sb copy_file_range() code
>   fs: add support for copy file range from another fs
>   fs: add support for copy file range to another fs
>   ovl: add support for copy file range from another fs
>   ovl: add support for copy file range to another fs
>
>  fs/overlayfs/file.c      |  35 ++++++++++++
>  fs/overlayfs/ovl_entry.h |   7 ++-
>  fs/read_write.c          | 119 ++++++++++++++++++++++++++++-----------
>  include/linux/fs.h       |   2 +
>  4 files changed, 130 insertions(+), 33 deletions(-)
>
> --
> 2.54.0
>

Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

[Amir Goldstein]

On Thu, Jul 23, 2026 at 3:05 PM Daan De Meyer <daan.j.demeyer@gmail.com> wrote:
>
> Hi Amir,
>
> I tested the series on top of f6cde11eb46e and cherry-picked these
> selftests:
>
> https://github.com/daandemeyer/vfs/commit/0b0e47d408311fe2b4a3e1711656f836b56e10f4
>
> All four tests failed.
>
> The accounting test reports two reads and writes, and 128 KiB
> accounted in each direction, for one 64 KiB copy. The outer and
> recursive backing-file VFS calls both account the operation.
>
> The credential test fails with EPERM. The explicit source check uses
> the source mount credentials, but the recursive VFS call checks the
> real source again while the destination mount credentials are active.
>
> The permission-order test times out because the real source
> FAN_ACCESS_PERM event happens after the destination inode has been
> locked. The process handling the event cannot update the destination
> while the copy is waiting for its response.
>
> Finally, denying that permission event still clears the destination's
> setuid and setgid bits. ovl_copyfile() removes them before checking
> permission on the real source.
>
> It looks like the root cause is that OverlayFS-to-OverlayFS is
> classified as FS_COPY_SAME_FS before the FOP_CROSS_FS_COPY checks.
> That leaves it on the existing recursive VFS path, so these issues
> remain even with the series applied.

I am baffled by this statement.

As far as I can see, OverlayFS-to-OverlayFS, which is classified
as FS_COPY_SAME_FS should not have changed behavior at all.
That was my intention at least, maybe I have a bug (?).

If I am right and behavior did not change then what are you saying?
That OverlayFS-to-OverlayFS copy_file_range() in upstream has issues?
Are those issues unique to copy_file_range() or also exist for clone
and splice and regular read/write?

Note the overlayfs model - do every operation on both overlayfs mount
(with user creds) and on backing mount (with ovl mounter creds).
Taking this model into consideration, what in your opinion is broken w.r.t
upstream [1] behavior of OverlayFS-to-OverlayFS copy?

Thanks,
Amir.

[1] upstream + this fix
https://lore.kernel.org/linux-unionfs/20260712122421.203113-1-amir73il@gmail.com/

Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

[Daan De Meyer]

> As far as I can see, OverlayFS-to-OverlayFS, which is classified
> as FS_COPY_SAME_FS should not have changed behavior at all.
> That was my intention at least, maybe I have a bug (?).

I am sorry, I forgot to mention that all of these issues are issues
with upstream overlayfs,
not with your patchset. I was trying to make the argument that to
solve the issues that are
already in upstream overlayfs and to introduce cross sb
copy_file_range() we need to move
away from recursively calling vfs_copy_file_range() within overlayfs
(and anywhere else really)
as its internals are really not intended for being called recursively.

`ovl_copyfile()` locks the overlay destination, removes privileges,
and then calls `vfs_copy_file_range()`
on the backing files under the destination OverlayFS mount credentials.

This has three observable consequences:

1. The recursive VFS call accounts one userspace copy twice.
2. When the files are on different OverlayFS mounts, the backing
source permission check uses the
destination mount credentials rather than the source mount credentials.
3. Backing permission hooks run while the overlay destination inode is
locked and after privileges
have been removed. A permission listener that accesses the destination
can deadlock, and a denied
backing check leaves the destination setid bits cleared.

Clone and dedupe use the same `ovl_copyfile()` helper and share the
credential and locking issue;
clone also shares the killpriv issue. Splice does not have the same
mixed-credential problem because
its source and destination operations are separate.

If anyone else thinks we should fix these pre-existing issues, then I
don't think recursively calling into
vfs_copy_file_range() is the way to go. If they're deemed not
important, then recursively calling into
vfs_copy_file_range() is probably fine.

Cheers,

Daan

On Thu, 23 Jul 2026 at 15:36, Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Thu, Jul 23, 2026 at 3:05 PM Daan De Meyer <daan.j.demeyer@gmail.com> wrote:
> >
> > Hi Amir,
> >
> > I tested the series on top of f6cde11eb46e and cherry-picked these
> > selftests:
> >
> > https://github.com/daandemeyer/vfs/commit/0b0e47d408311fe2b4a3e1711656f836b56e10f4
> >
> > All four tests failed.
> >
> > The accounting test reports two reads and writes, and 128 KiB
> > accounted in each direction, for one 64 KiB copy. The outer and
> > recursive backing-file VFS calls both account the operation.
> >
> > The credential test fails with EPERM. The explicit source check uses
> > the source mount credentials, but the recursive VFS call checks the
> > real source again while the destination mount credentials are active.
> >
> > The permission-order test times out because the real source
> > FAN_ACCESS_PERM event happens after the destination inode has been
> > locked. The process handling the event cannot update the destination
> > while the copy is waiting for its response.
> >
> > Finally, denying that permission event still clears the destination's
> > setuid and setgid bits. ovl_copyfile() removes them before checking
> > permission on the real source.
> >
> > It looks like the root cause is that OverlayFS-to-OverlayFS is
> > classified as FS_COPY_SAME_FS before the FOP_CROSS_FS_COPY checks.
> > That leaves it on the existing recursive VFS path, so these issues
> > remain even with the series applied.
>
> I am baffled by this statement.
>
> As far as I can see, OverlayFS-to-OverlayFS, which is classified
> as FS_COPY_SAME_FS should not have changed behavior at all.
> That was my intention at least, maybe I have a bug (?).
>
> If I am right and behavior did not change then what are you saying?
> That OverlayFS-to-OverlayFS copy_file_range() in upstream has issues?
> Are those issues unique to copy_file_range() or also exist for clone
> and splice and regular read/write?
>
> Note the overlayfs model - do every operation on both overlayfs mount
> (with user creds) and on backing mount (with ovl mounter creds).
> Taking this model into consideration, what in your opinion is broken w.r.t
> upstream [1] behavior of OverlayFS-to-OverlayFS copy?
>
> Thanks,
> Amir.
>
> [1] upstream + this fix
> https://lore.kernel.org/linux-unionfs/20260712122421.203113-1-amir73il@gmail.com/

Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

[Amir Goldstein]

On Thu, Jul 23, 2026 at 3:54 PM Daan De Meyer <daan.j.demeyer@gmail.com> wrote:
>
> > As far as I can see, OverlayFS-to-OverlayFS, which is classified
> > as FS_COPY_SAME_FS should not have changed behavior at all.
> > That was my intention at least, maybe I have a bug (?).
>
> I am sorry, I forgot to mention that all of these issues are issues
> with upstream overlayfs,
> not with your patchset. I was trying to make the argument that to
> solve the issues that are
> already in upstream overlayfs and to introduce cross sb
> copy_file_range() we need to move
> away from recursively calling vfs_copy_file_range() within overlayfs
> (and anywhere else really)
> as its internals are really not intended for being called recursively.
>
> `ovl_copyfile()` locks the overlay destination, removes privileges,
> and then calls `vfs_copy_file_range()`
> on the backing files under the destination OverlayFS mount credentials.

Yes absolutely by design

>
> This has three observable consequences:
>
> 1. The recursive VFS call accounts one userspace copy twice.

I think that is fine or at least not so bad.
same "problem" exist for overlayfs read/write and has been that way
forever. nobody complained.

> 2. When the files are on different OverlayFS mounts, the backing
> source permission check uses the
> destination mount credentials rather than the source mount credentials.

You mean that after the fix [1] it is *also* checked by destination mount
creds after being checked with source mount creds.

There is no security risk here, so I think this is something we should
leave as a known and documented issue, because solving that would
be as complicated as what you posted and I don't want to go there.

> 3. Backing permission hooks run while the overlay destination inode is
> locked and after privileges
> have been removed. A permission listener that accesses the destination
> can deadlock,

There are endless variants to these potential deadlocks with permission
events. This was discussed recently on this thread:
https://lore.kernel.org/linux-fsdevel/xycqm3qrhjg3uplpmozwo7nterl5tnuarghowmh3h3mv3thh6u@apagf4kqlkg6/

> and a denied
> backing check leaves the destination setid bits cleared.

Nothing new here - not even a bug or a problem IMO.
The state of privs after a write that MAY have started and returned an
error is undefined.
Always been this way in all the write APIs.

IOW, all the problems you listed are overlayfs behavior by design,
which AFAIK have been like this forever.

Do you have any reports on new issues specific to this patch set and
the new overlayfs to/from basefs copy?

Do you know of any real world workloads that are significantly impacted
by the existing upstream issues that you listed?

Thanks,
Amir.

Re: [RFC][PATCH 0/5] Proposal for Cross-fs copy_file_range()

[Gao Xiang]

Hi Amir,

On Thu, Jul 23, 2026 at 01:48:43PM +0200, Amir Goldstein wrote:
> Hi all,
> 
> Daan De Meyer requested a way to do copy_file_range() from overlayfs
> to/from another fs, where if that fs is the base fs of overlayfs layer
> the copy could be an efficient clone.
> 
> TBH, he also requested support also for cross-fs clone_file_range(),
> but I am not happy about providing that.
> 
> copy_file_range() already supports cross-sb efficient copy (e.g. with
> NFS/SMB server-side copy).

I once had a long-term goal of supporting copy_file_range() between
overlayfs and EROFS for file-backed mounts, as long as the EROFS inodes
are plain (i.e. uncompressed). Such cross-fs copies could be decomposed
into one or more sub-copies from the EROFS backing file to the
overlayfs upper file, so the underlying backing filesystem can perform
the actual data transfer. If the backing filesystem supports reflinks,
those operations could even be implemented as efficient reflinks.

This would greatly optimize overlayfs copy-up for file-backed EROFS
mounts.

I think this should be feasible, although I haven't had time to work
on it yet. If clean interfaces in this area make that easier, I'd be
very happy to make use of them and enable this later.

Thanks,
Gao Xiang

> 
> The current limitation of staying on the same fstype is mainly an
> internal technical limitation (choosing the right f_op), which is
> something that this RFC is trying to address.
> 
> The overlayfs implementation itself is pretty trivial.
> 
> Thanks,
> Amir.
> 
> 
> Amir Goldstein (5):
>   fs: clarify cross-sb copy_file_range() code
>   fs: add support for copy file range from another fs
>   fs: add support for copy file range to another fs
>   ovl: add support for copy file range from another fs
>   ovl: add support for copy file range to another fs
> 
>  fs/overlayfs/file.c      |  35 ++++++++++++
>  fs/overlayfs/ovl_entry.h |   7 ++-
>  fs/read_write.c          | 119 ++++++++++++++++++++++++++++-----------
>  include/linux/fs.h       |   2 +
>  4 files changed, 130 insertions(+), 33 deletions(-)
> 
> -- 
> 2.54.0
>