RFC: Should copy_file_range(2) return after a few seconds?

Hi,

Peter Much reported a problem on the freebsd-fs@ mailing
list on Oct. 21 under the Subject: "Why does rangelock_enqueue()
hang for hours?".

The problem was that he had a copy_file_range(2) copying
between a large NFS file and a local file that was taking 2hrs.
While this copy_file_range(2) was in progress, it was holding
a rangelock for the entire output file, causing another process
trying to read the output file to hang, waiting for the rangelock.

Since copy_file_range(2) is not any standard (just trying to
emulate the Linux one), there is no definitive answer w.r.t.
should it hold rangelocks.  However, that is how it is currently
coded and I, personally, think it is appropriate to do so.

Having a copy_file_range(2) syscall take two hours is
definitely an unusual case, but it does seem that it is
excessive?

Peter tried a quick patch I gave him that limited the
copy_file_range(2) to 1sec and it fixed the problem
he was observing.

Which brings me to the question...
Should copy_file_range(2) be time limited?
And, if the answer to this is "yes", how long do
you think the time limit should be?
(1sec, 2-5sec or ??)

Note that the longer you allow copy_file_range(2)
to continue, the more efficient it will be.

Thanks in advance for any comments, rick