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

From: Mark Johnston <>
Date: Fri, 5 Jul 2019 10:38:45 -0400
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
> 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.
Received on Fri Jul 05 2019 - 12:38:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC