copy_file_range: Fix overlap checking

[markj]

Summary

The check for range overlap did not correctly handle negative offests,
as the addition inoff + len is promoted to an unsigned type. Moreover,
the range-locking code did not check for overflow.

Add some checks to make sure the ranges are valid. vn_copy_file_range()
has weaker checks: it also returns an error for a negative offset, but
overflow results in the copy length being truncated. Is this behaviour
required for compatibility with Linux?

[rmacklem]

sys/kern/vfs_syscalls.c

5087

The "len" argument is often just SSIZE_MAX to
copy to EOF on the input file, so I think truncation
of "off + len" to OFF_MAX (or whatever it is called?)
when it overflows is correct.

[markj]

Truncate lengths rather than returning an error.

[rmacklem]

sys/kern/vfs_syscalls.c

5087

I think this is ok.

However, rangelocking should handle the
full uint64_t file size, I think? (The argument
is vm_ooffset_t, which appears to be uint64_t.)

If so, since len is already clipped to SSIZE_MAX
above here in the code, this clipping should not
be needed, I think?

[markj]

sys/kern/vfs_syscalls.c

5087

You're right. I was also concerned about overflow in the check immediately below in the invp == outvp case, but clamping len to SSIZE_MAX is sufficient there too.

[markj]

Remove unnecessary clamping.

[rmacklem]

This looks fine to me.