[Bug 273962] copy_file_range does not work on shared memory objects

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962

--- Comment #4 from Rick Macklem <rmacklem@FreeBSD.org> ---
Long ago when I first worked on 6th edition
(late 1970s) there was the "everything was
a file" philosophy.  However, things like
shared emeory did not exist. The fact that
the code does not use vnodes suggests they
are not files to me.

Right now the code (including
vn_generic_copy_file_range() which is
the fallback) uses vnodes.
(The error is actually returned because
 there is no vnode associated with the
 file descriptor.)

To do this would require a separate chunk
of code directly under the syscall to do
the copying. A simple loop doing shm_read()/shm_write()
should work, I'd guess (but it will need to be
done as a special case when there are no vnodes) and
needs to check for "no overlapping region", since that
is part of the syscall interface.

The original intent of copy_file_range(2)
was to enable file systems to optimize copying,
such as NFSv4 doing the copy locally in the
NFS server instead of reading data to the client
and writing it back to the server.
(The fallback was implemented to simplify the
case where the file system does not have a
specific VOP_COPY_FILE_RANGE().)
Since this case is not file system related,
the above does not really apply.
(I suppose do so saves a few syscalls.)

I will ask on freebsd-fs@ to see if others
feel this capability is needed.

Feel free to come up with a patch.
If others do not, I may do so someday.
(It would be called from kern_copy_file_range()
when f_vnode == NULL.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.