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

Hans Petter Selasky wrote:
>On 2019-07-05 02:28, Rick Macklem wrote:
>> 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.
>
>How can you kill a program stuck on copy_file_range(2) w/o catching signals?
Well, if "stuck" means sleeping somewhere inside the VOP_WRITE() call for
the file system, I think it is "stuck" forever, just like write(2), isn't it?

For NFS, the "intr" option might allow write(2) to return EINTR, but it often
takes a forced dismount (actually "umount -N") to get it "unstuck".

However, I think for the case where the signal is detected outside of
VOP_READ()/VOP_WRITE() in the copy loop, it does make sense to terminate
it and I think the suggestion of returning "bytes copied" instead of EINTR is
a good one.

rick