should a copy_file_range(2) syscall be interrupted via a signal

[Mark Johnston]

On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote:
> Hi,
> 
> I have been working on a Linux compatible copy_file_range(2) syscall
> (the current code can be found at https://reviews.freebsd.org/D20584).
> 
> One outstanding issue is how it should deal with signals.
> Right now, I have vn_start_write() without PCATCH, so that it won't be
> interrupted by a signal, but I notice that vn_write() {ie. write syscall } does
> have PCATCH on vn_start_write() and so does vn_rdwr() when it is called
> without IO_NODELOCKED.
> 
> I am thinking that copy_file_range(2) should do this also.
> However, if it returns an error, it is impossible for the caller to know how much
> of the data range got copied.

Couldn't copy_file_range() return the number of bytes copied in this
case?  (The Linux man page notes that short writes are possible.) I
would expect to see the same error handling that we have in
dofilewrite(), where certain errnos are squashed.

> What do you think the copy_file_range(2) code should do?

I'd find it surprising if copy_file_range() isn't interruptible.