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

On Thu, Jul 23, 2026 at 3:54=E2=80=AFPM 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/xycqm3qrhjg3uplpmozwo7nterl5tnuarghow=
mh3h3mv3thh6u@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.