From nobody Wed Sep 20 23:21:46 2023 X-Original-To: freebsd-fs@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 4RrZLJ5xz6z4vKRL for ; Wed, 20 Sep 2023 23:22:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RrZLJ1SkQz4c9l; Wed, 20 Sep 2023 23:22:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=GRkbv0Bl; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::42d as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-68fb98745c1so260108b3a.1; Wed, 20 Sep 2023 16:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695252118; x=1695856918; 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=cUGd+OSV4/eowR4qXbHGJ1UFZTYmf3A0kdoyNY3U2+M=; b=GRkbv0BliZl4NVvwTukgzonkZTaVfMwwJRfIXa3yW1mrQzdM9V23BV2/uF1Kxs6t0/ nvHWacQ9h2Y7BVjWuDh9HsObOVlaVuPkb5s7qFEMiw1Y49pGR786WbDQRWc6WJ84YqGV o26xlzc7xyuNPltb/VKvXahvKXqbPnH/Tm6hhpts7neBSBRTgsV7BdeMrkdRsxWNgbpL rQGADiGJ14bXiok3rcpcivgwf/5/fX49PfhxTaEIJuNuLLR1CX55etuHp2u1yVwslsXy f5d/Ug0VDu4/ERiG97+444r8Xsi14/xnUrIX2tYmjUoKATfcSVOgUvoc5AfhPpw6xF3M p4Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695252118; x=1695856918; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cUGd+OSV4/eowR4qXbHGJ1UFZTYmf3A0kdoyNY3U2+M=; b=sdCaL13BOjKXo9SeMd6iYIBhWA6iT7gNL6rt1dvCqk8DNrLTqxmWEuI2ZsoWym0fSX 9N9BTeE1lGGEWte5tVRCkN7gTgMO7KBaI8VmKNxv3HIYRw2gL5pKZXGeTAZfSYX4X4OX paAfoyTXU2MM0Gevp78oP8VnF1QONhRJm3bewN8VF7jnwLe/XY3zliT9byU831P+y3+r UXWdqF1KNfEgFtmVW8w/LvgHzVzX3VEKc5QRP/qQQcr3nVoogEX2M4MT4CJOW5mgKqk8 bdYRtOQIRgIVPUFAMyvKjKYJ+qGS0P62IlxcgiAQ48buGKeL6WmOfgJi/z0K7WQeKNFS 8InA== X-Gm-Message-State: AOJu0Yzhs/9IWd7xhCoFOEKFDdpR1ZxfUdIxLGrq8hWVmkSjRjH3kHov BQBBSvQq1eTpmZ6AXhYkaKdrsxt8pf91w/TRQbQ2n3I= X-Google-Smtp-Source: AGHT+IFtmcWrcVZcOeq4P3a6Oooba3i0UCYD5/hAPz+P+VFthRmmEx14I22xKXPPibXjKjp9WCUMKyYHxwE8+hkeUgA= X-Received: by 2002:a05:6a20:160c:b0:136:ea0e:d23 with SMTP id l12-20020a056a20160c00b00136ea0e0d23mr4974894pzj.11.1695252117716; Wed, 20 Sep 2023 16:21:57 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Wed, 20 Sep 2023 16:21:46 -0700 Message-ID: Subject: Re: RFC: Should copy_file_range(2) work for shared memory objects? To: Alan Somers Cc: Freebsd fs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: - X-Spamd-Result: default: False [-1.98 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.01)[0.010]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42d:from]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org] X-Rspamd-Queue-Id: 4RrZLJ1SkQz4c9l On Wed, Sep 20, 2023 at 4:09=E2=80=AFPM Rick Macklem wrote: > > On Wed, Sep 20, 2023 at 3:07=E2=80=AFPM Alan Somers = wrote: > > > > On Wed, Sep 20, 2023 at 3:05=E2=80=AFPM Rick Macklem wrote: > > > > > > Right now (as noted by PR#273962) copy_file_range(2) > > > fails for shared memory objects because there is no > > > vnode (f_vnode =3D=3D NULL) for them and the code uses > > > vnodes (including a file system specific VOP_COPY_FILE_RANGE(9)). > > > > > > Do you think copy_file_range(2) should work for shared memory objects= ? > > > > > > This would require specific handling in kern_copy_file_range() > > > to work. I do not think the patch would be a lot of work, but > > > I am not familiar with the f_ops and shared memory code. > > > > > > rick > > > > This sounds annoying to fix. But I think we ought to. Right now > > programmers can assume that copy_file_range will work for every type > > of file. We don't document an EOPNOTSUP error code or anything like > > that. Does it work on sockets, too? > No. I guess I have a different definition of "file" (unless you meant > "filedesc"?). I cannot see how a "range is defined for sockets > or named pipes or...". It currently checks for a f_vnode, which > probably is not enough. (I haven't figured out what path_fileops > are, so I do not know if they work?) > > I can see how it can be implemented for shared memory objects. > However, this is going to take a fair amount of work, since they > do not use vnodes. > I think it goes something like this: > - Create a new fileops (f_copy_file_range), since it needs to use > the correct range lock variables (in shmfd instead of vnode ones). > - Move most of kern_copy_file_range() into vnodeop_copy_file_range() > and call f_copy_file_range() from kern_copy_file_range(). > - Create a shm_copy_file_range() that does the correct range locking > and then copies via uiomove(). > This would be a KABI change, so I do not think it could be MFC'd. > > I think there is a need for copy_file_range(2) to return EOPNOTSUP > for cases it will never handle. (I need to test AF_LOCAL sockets, > since I think they have vnodes?) copy_file_range(2) does currently return EOPNOTSUPP for unix domain (AF_LOCAL) sockets. The man page needs to be fixed, whether or not support for shared memory objects is added. rick > > rick