Date: Sat, 23 Sep 2023 08:15:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 273962] copy_file_range does not work on shared memory objects Message-ID: <bug-273962-227-pMhMRVxKEU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273962-227@https.bugs.freebsd.org/bugzilla/> References: <bug-273962-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273962 --- 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 guaran= tees about what happens if you concurrently write to the range being read or read from the range being written.=20=20 In the absence of any such guarantees, I'd expect the semantics of this cal= l 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 sensib= le 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 amou= nt. All of these are exposed in the `file*` that `kern_copy_file_range` has acc= ess to. In the worst case, this should still be faster than doing it in usersp= ace 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 cod= e to know in advance whether a file descriptor that it has been passed (in my ca= se, via a UNIX domain socket) is one that can or can't be used with copy_file_r= ange 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273962-227-pMhMRVxKEU>