From nobody Sun Nov 9 03:40:25 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d3z990xmqz6G7x7 for ; Sun, 09 Nov 2025 03:41:01 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d3z9828Qbz3qpl for ; Sun, 09 Nov 2025 03:41:00 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5A93eQX6032994; Sun, 9 Nov 2025 05:40:29 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5A93eQX6032994 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5A93ePhb032993; Sun, 9 Nov 2025 05:40:25 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 9 Nov 2025 05:40:25 +0200 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT , "Peter 'PMc' Much" Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; HAS_XAW(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEFALL_USER(0.00)[kib]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4d3z9828Qbz3qpl On Sat, Nov 08, 2025 at 06:09:15PM -0800, Rick Macklem wrote: > On Sat, Nov 8, 2025 at 4:43 PM Konstantin Belousov wrote: > > > > On Sat, Nov 08, 2025 at 03:22:37PM -0800, Rick Macklem wrote: > > > 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 > > > > For me, making a syscall limited by runtime is very strange idea. > > IMO it should not be done. > > > > What can be done, I think, is to add signal interruption points into > > the copying loop. AFAIR we request a chunk to be copied, for some > > size of the chunk. After the copy is done, kernel could use > > sig_intr() to check for either interruption or suspend conditions. > > If non-zero is returned, you might finish the loop earlier, reporting > > the partial copy. > > > It already interrupts when a signal like C is posted. > > The reporter didn't want the copy (he was actually using "cat") > to terminate. He wanted to read the output file when it was > only partially copied, which doesn't work because of the > rangelock. (It appears it does work on Linux.) Apps can install timer which would generate SIGALRM after 1 or 2 secs. Then the syscall is interrupted and partial copy is reported. > > A partial copy_file_range() is normal and an NFSv4.2 server > will return a partial copy after 1sec or so since there is a > general understanding (not wired down in any RFC) that > an RPC should always reply in 1-2sec. > > rick