Re: RFC: Should copy_file_range(2) work for shared memory objects?
Date: Thu, 21 Sep 2023 00:39:05 UTC
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.)