fix vn_generic_copy_file_range() so that it will return if a signal needs to processed

[rmacklem]

Summary

Without this patch, when vn_generic_copy_file_range() is
doing a large copy, it will remain in the function for a
considerable amount of time, delaying handling of any
outstanding signals until the copy completes.

This patch adds checks for signals that need to be
processed after each successful data copy cycle.
When sig_intr() returns non-zero, vn_generic_copy_file_range()
will return.
The check "if (len < savlen)" ensures that some data
has been copied, so that progress will be made.

Note that, since copy_file_range(2) is allowed to
return fewer bytes copied than requested, it
will never return EINTR/ERESTART when sig_intr()
returns non-zero.

I'll let kib@ decide where sig_intr() should actually
go. It is his code and seems to work for testing sofar.

Test Plan

Did a large copy using a program that does
copy_file_range() in a loop and also a large
copy via the recently patched "cp", then
used <ctrl>C to terminate the copy while in
progress.

[asomers]

LGTM. A sig_intr.9 man page would be nice, if that function ends up being globally accessible.

[kib]

D26628 for sig_intr().

[rmacklem]

Use the variant of sig_intr() in D26628.

Testing with the D22628 variant of sig_intr()
has not found problems with it.

Obviously this commit will wait for D22628
to be committed.

[kib]

Rick, thank you for the testing. I am waiting for review of D26628, then I will ask Peter Holm to test it. The sleepq changes are somewhat delicate.

sys/kern/vfs_vnops.c

3015 ↗

(On Diff #77782)

I suggest to use bool for interrupted.

3177 ↗

(On Diff #77782)

Then this line would be interrupted = sig_intr() != 0;.