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

On Thu, Jul 23, 2026 at 3:05=E2=80=AFPM 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/0b0e47d408311fe2b4a3e1711656f83=
6b56e10f4
>
> 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@gmai=
l.com/