Re: RFC: Should copy_file_range(2) work for shared memory objects?

On Wed, Sep 20, 2023 at 4:54 PM John F Carr <jfc@mit.edu> wrote:
>
> On Sep 20, 2023, at 16:47, Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > Right now (as noted by PR#273962) copy_file_range(2)
> > fails for shared memory objects because there is no
> > vnode (f_vnode == NULL) for them and the code uses
> > vnodes (including a file system specific VOP_COPY_FILE_RANGE(9)).
> >
> > Do you think copy_file_range(2) should work for shared memory objects?
> >
> > This would require specific handling in kern_copy_file_range()
> > to work.  I do not think the patch would be a lot of work, but
> > I am not familiar with the f_ops and shared memory code.
> >
> > rick
> >
>
> According to a Linux man page, some failure modes are
>
>        EINVAL Either fd_in or fd_out is not a regular file.
>
>        EOPNOTSUPP (since Linux 5.19) The filesystem does not support this operation.
>
>        EXDEV (since Linux 5.19)
>             The files referred to by fd_in and fd_out are not on the
>             same filesystem, and the source and target filesystems are
>             not of the same type, or do not support cross-filesystem copy.
>
> According to the FreeBSD man page
>
>      The copy_file_range() system call is expected to be compatible with the
>      Linux system call of the same name.
>
So, I guess you are advocating for sticking with "Linux compatible"?
I'm fine with that, but we'll see what others say.

Thanks for your comments, rick
ps; When I go look at the Linux man page, I often get an out-of-dat
     one, so I am never sure what Linux currently does. (It is also
     confusing because some distros implement copy_file_range()
     in their libc instead of the kernel. I think more recent Linux kernels
     do support the syscall.)