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

From: Alan Somers <>
Date: Fri, 5 Jul 2019 08:26:22 -0600
On Thu, Jul 4, 2019 at 6:29 PM 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.
> What do you think the copy_file_range(2) code should do?
> Thanks, rick
> ps: I've used FreeBSD-current_at_ this time, to see if I get more replies than I
>       did using FreeBSD-fs_at_.

I though copy_file_range(2) is allowed to return short.  Why can't it
do that if it gets interrupted?
Received on Fri Jul 05 2019 - 13:35:01 UTC

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