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

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

--- Comment #9 from David Chisnall <theraven@FreeBSD.org> ---
(In reply to Rick Macklem from comment #7)

What are the range locking guarantees?  I don't see anything in the man page
(ours or Linux's) that mentions anything about locking ranges or any guarantees
about what happens if you concurrently write to the range being read or read
from the range being written.  

In the absence of any such guarantees, I'd expect the semantics of this call to
be the equivalent of a read/write loop on the two fds.  My expectation for the
fallback path was that it would:

1. stat the source to see how big it was.
2. Allocate a temporary buffer to hold whichever is smaller out of a sensible
copy size or the amount remaining to be copied.
3. Read from the source file into that buffer.
4. Write from the buffer to the destination.
5. Loop to copy any more if 2 allocated a buffer smaller than the copy amount.

All of these are exposed in the `file*` that `kern_copy_file_range` has access
to.  In the worst case, this should still be faster than doing it in userspace
because it will have fewer system call transitions.

Ideally, if the source is already in the buffer cache then we can avoid
allocating the buffer and just write directly from there, but that's not
necessary to make it usable.

My current problem with this call is that there is no way for userspace code to
know in advance whether a file descriptor that it has been passed (in my case,
via a UNIX domain socket) is one that can or can't be used with copy_file_range
and, after trying it, cannot differentiate between failures as a result of
unsupported file descriptor types or as a result of other errors.  Ideally, I'd
be able to use this syscall with anything where the userspace fallback path
worked.

Alternatively, if the error from unsupported file descriptor types, the
fallback code could be in the libc wrapper.

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