From nobody Sat Sep 23 08:15:34 2023 X-Original-To: doc@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 4Rt2526bSpz4vGCp for ; Sat, 23 Sep 2023 08:15:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rt2525bffz4R3t for ; Sat, 23 Sep 2023 08:15:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695456934; a=rsa-sha256; cv=none; b=ZD+sZg+KcvF7++d8tiasR5Qi+7IJyMlQJF55Zc/FrFgHtp1BmVOmQ/q5RIPwxYsm/poe2W 1nYZ2fHfNcnx1jzgQ4C4ir3GvI5Rt/2xMECQ53nf2t/yOG4igmRD//UmSNAxBQmrxQL44+ tu1796T3sznj+Ob6tVRBe9EAMd9wBdAUqrCLnP7ESatcYKN6NnW1GE/tysZtA3o/1og94r vJf6Lo3tNZwikL5ki951zROnaGxjGn7CMF7z30Fk/9g41YfYmCAO7mMDiQVbggjyakRhxY VyClu/tyBVoTGlH4b6MZ6vMWXWxucuTnKqNCzxN65kuH+CODqBL1zIvm9vwKjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695456934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lfVsZ/vy99N2e+VPkzXsYvtKhIJsTLwysw4vaeLVwno=; b=JJpeVl2ArRdKSh+f63FAE1GR4TNxy6s0nMuGEpOJhZfVYPKttPsqYlUPiAFijDTlVIK2ui xrS04I4T7JElDbnaqU3aAs9XQo/+28G9Gm1YgguGntss2UqwIx9+xGRCccemg6cY7IuBie maoQ9AJk7y+NgPJ7ZLEc3G80ljnZvpF5s9h+94KmAxWRwaDrmblPtvYg+TmnyHZVdaZ1VJ CPuIvZdM6U5XGWG0blbBv1rVp945kMPVUQ6uyGYJf9eTpFCMJFnvVxDpHxnwpwHYaFmYXw pIJWZVFNMjnGeCZTx0/pyMGT0Vo/oq9NKgriNquI/aI6E8hP4zKb/hw9MIkf5w== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Rt2524drMzx51 for ; Sat, 23 Sep 2023 08:15:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 38N8FYSM070817 for ; Sat, 23 Sep 2023 08:15:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 38N8FY1j070816 for doc@FreeBSD.org; Sat, 23 Sep 2023 08:15:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 273962] copy_file_range does not work on shared memory objects Date: Sat, 23 Sep 2023 08:15:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Documentation X-Bugzilla-Component: Manual Pages X-Bugzilla-Version: Latest X-Bugzilla-Keywords: needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Documentation project List-Archive: https://lists.freebsd.org/archives/freebsd-doc List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-doc@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273962 --- Comment #9 from David Chisnall --- (In reply to Rick Macklem from comment #7) What are the range locking guarantees? I don't see anything in the man page (ours or Linux's) that mentions anything about locking ranges or any guaran= tees about what happens if you concurrently write to the range being read or read from the range being written.=20=20 In the absence of any such guarantees, I'd expect the semantics of this cal= l to be the equivalent of a read/write loop on the two fds. My expectation for = the fallback path was that it would: 1. stat the source to see how big it was. 2. Allocate a temporary buffer to hold whichever is smaller out of a sensib= le copy size or the amount remaining to be copied. 3. Read from the source file into that buffer. 4. Write from the buffer to the destination. 5. Loop to copy any more if 2 allocated a buffer smaller than the copy amou= nt. All of these are exposed in the `file*` that `kern_copy_file_range` has acc= ess to. In the worst case, this should still be faster than doing it in usersp= ace because it will have fewer system call transitions. Ideally, if the source is already in the buffer cache then we can avoid allocating the buffer and just write directly from there, but that's not necessary to make it usable. My current problem with this call is that there is no way for userspace cod= e to know in advance whether a file descriptor that it has been passed (in my ca= se, via a UNIX domain socket) is one that can or can't be used with copy_file_r= ange and, after trying it, cannot differentiate between failures as a result of unsupported file descriptor types or as a result of other errors. Ideally,= I'd be able to use this syscall with anything where the userspace fallback path worked. Alternatively, if the error from unsupported file descriptor types, the fallback code could be in the libc wrapper. --=20 You are receiving this mail because: You are on the CC list for the bug.=