From nobody Sun Nov 09 04:06:06 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 4d3zkS6sXqz6G9gF for ; Sun, 09 Nov 2025 04:06:24 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d3zkS467zz3vbY for ; Sun, 09 Nov 2025 04:06:24 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-64149f78c0dso2258497a12.3 for ; Sat, 08 Nov 2025 20:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762661178; x=1763265978; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oa7c+lUYNhgANcruC5Ks071uHd5oLrCUzNXCtaebTxg=; b=HeJKn1PIfz6EdJzB9zk0H2zgEzC8DWU6CMF/N37Lt1zCqBmEam6kQo78EZsykgin37 D1vBxAQ8dwSAGlYNSeUORg8rzxlOejnuAdS+8JaVesv/+Idu+CWbzsyHElzgU8owYexm Y62/H0mv9rO/H1+NI9+sMAl/5eXdvRY7DKy6f5JdgaDH7ij0rpS423LKA4MQ3JtLFYRh ocSPVQrVQHA6UszSA2ub2uKYGBrErekVypHQc9EMVSYpKa99CeBz6rSc8oMfzfarz4Ku dyj+rfIuKJTqnjWFZ7KJBVidADZ8QQPN5cJ9geZSff7nnq1/6c7Oh0+fkmkAwVOVByqO DmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762661178; x=1763265978; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=oa7c+lUYNhgANcruC5Ks071uHd5oLrCUzNXCtaebTxg=; b=aeju0r0reILeOjIMdid+UHYAwGjv0BGZuJj4un7RNzHOtFaWwYyw4Bcj5+xZUnKlt/ w6jLvaOoW4TQD1Zo9Fp+87jCgPdnUzC6jn03sfyrkL8+1qYP+T2TxzXco1re+JAE0Wkl ym8rMpBJYFsHNe+bTgvuvky853cK52Abzt/XzoLigdtn7HXHin3mZ5uOC1v5DZgqDWjI 5aWWruu4Rzq069Rj4DlivH6aClwqu6YdgEhP6/4e93JZnxHyTiszbj6fat9D7oN0Y44m Fs2U9VVJ3+qMn5I/TYED1kOnJamvvq1ICMMZQb0K52RuPndAPTfAcPCerZAsTyoPwCEd 1ACw== X-Gm-Message-State: AOJu0YzLZEcA1vM/eyIzzXf2YXvSkbY4J3q0kcC5NVeebPif/trjSw2e txyxzMxApdu2ZC+gTlR5p4DsGPR3B8NP0HiHkEno/x5nTPZsW9ngnYOfw7Zqfc63qe6xcrCoH8B OOYO3aQ8ymL6VRO5cruKwtmEYRHB4TQ== X-Gm-Gg: ASbGncv4nugm9gtp+JibY7k21LHjwqfiFtamaK86d1YMw1LWVVAApOARuupqq3zufae LcLsE0Fh7M3Q7/+LSJ39e0NKiWg4cRgWQE0j7suSCsOglJWNQ00sqv7VhK6PyS7Mvu4INNH8Pt9 Svi49kVlVTMSrZJfN3pGm3LA0TJAI/1u378mOtr+OdpLK0OMJXfj1Pj5gN5dxXCGD33kGQ93phY jXGD9oXkjF6BETYT2xdbEsMXROIntpcWMIl/QJNcv+nlX0A5/sAevQiIfusGgD1t636VZbTULqt +78Vhu96RVrm9Gtfeb/9cIhceFkdoJVJEpNbig== X-Google-Smtp-Source: AGHT+IEYhZmykYcbYK4D2di+hQ66CQ81K7N3CNI9AeR7cCM0d9ivB7xvf46KqIJpyy5F3xFkRyUH06BKj/+FwoueTk4= X-Received: by 2002:a05:6402:4559:b0:63e:6511:4186 with SMTP id 4fb4d7f45d1cf-6415ea4e7cdmr3569290a12.37.1762661178036; Sat, 08 Nov 2025 20:06:18 -0800 (PST) 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 References: In-Reply-To: From: Rick Macklem Date: Sat, 8 Nov 2025 20:06:06 -0800 X-Gm-Features: AWmQ_bmcbiPMYf6BUed96V7ToK-vmBOpKGbPn3Fjdgjykn-tuO5Rx7a9MyjsxME Message-ID: Subject: Re: RFC: Should copy_file_range(2) return after a few seconds? To: Konstantin Belousov Cc: FreeBSD CURRENT , "Peter 'PMc' Much" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d3zkS467zz3vbY On Sat, Nov 8, 2025 at 7:41=E2=80=AFPM Konstantin Belousov wrote: > > On Sat, Nov 08, 2025 at 06:09:15PM -0800, Rick Macklem wrote: > > On Sat, Nov 8, 2025 at 4:43=E2=80=AFPM 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. Yep, although in Peter's case it was just "ca(1)t". Also, the timeout coul= d be enabled via a flag in the flag argument to copy_file_range(2). That is probably simpler than a SIGALRM. (The current 1sec timeout flag for the NFS server is "in kernel only", but it's easy to expose it to the syscall. rick > > > > > 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 >