From nobody Wed Sep 20 23:47:44 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 4RrZwF2XKYz4vLZm for ; Wed, 20 Sep 2023 23:47:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 4RrZwD2s05z4f42; Wed, 20 Sep 2023 23:47:56 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=IREpzjnW; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-578d0d94986so222335a12.2; Wed, 20 Sep 2023 16:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695253675; x=1695858475; 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=lw7dBAB9mwhXRY3x0LYwT6DALYnP/V3AyQBUNPVFCiE=; b=IREpzjnWUHX3dmrhqGV7GbL6tknQXcbzvpm5t/wJGassY7apoBrwbeZwF+8Z+r2P3o N6BRj/J+8C+D5LY8Cve/HqlP2loG0RRfgyXfnu1vKKfE+bp3bn6TXhdwJ4ddcwymIxXQ eX+Z6+E2PMmLn/UkCmBYyLngpeiAM3GKbxxQmm43h0I8dsL4ij2xsiPFRHqC4C1cMUBJ wmjNia7N0/t9W28rJNz8spagtx1CpJjax1ev7LSxChaVdxb0XpGZkYo1qA3wwx4rwIUA RZhlWLFs2vytaARnAkxM0zve/SRxw70L5feWAfoqXlN0x9CvYarqbRqrHoaStoEJk4T0 eyjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695253675; x=1695858475; 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=lw7dBAB9mwhXRY3x0LYwT6DALYnP/V3AyQBUNPVFCiE=; b=GmJKaVg4eg08xOVvO4vO+692PliaXcSt6nC3m4Zs6MQFH8wbrIyRUWyYChw0nfxdOl npQuwSGIKVCYA74IGm1/h6DhYZsojdcJxtTjFwSvRgt7vvM/sormL5AuDLF6jwwShzPs yMW0w0qd827jsF7ts0R12lTRwl9VApaiyJ+QXUtGXhACk9Xng3loJRKownIsy1oKfCLH ET7FFqlmcAMxhn7DfCuBXc41FGdR6/DNZlb8GhKQzy+qJBBpwJAWmdDfH5iubsAdXWlS MxCZ936LQeQStnag9pqXXuDg7T0XelChZv2YV8iU6S1k/McZXNBjkibZ/HwKKS6abAmb 0Eow== X-Gm-Message-State: AOJu0YxIbDeLROOouUJ5/nQbvO5EVVUTtmETeP7CJlRodt7krSGw2pWO c28UjE14DVc18EdHbrpw3M5iHhCazz/5rJQexKaVaLQ= X-Google-Smtp-Source: AGHT+IEvmRwR2rKp4Ng2IbgYqGr9lJ5m7HLkmbU8p/rRdYMqo3/VFqG5aNyFHt3nhC7G78aLdTDlmlXJuICWWkK3ZhU= X-Received: by 2002:a05:6a20:4417:b0:14e:315b:d9c with SMTP id ce23-20020a056a20441700b0014e315b0d9cmr5066346pzb.22.1695253675229; Wed, 20 Sep 2023 16:47:55 -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:47:44 -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 [-2.98 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.99)[-0.990]; 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]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::531:from]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org] X-Rspamd-Queue-Id: 4RrZwD2s05z4f42 On Wed, Sep 20, 2023 at 4:21=E2=80=AFPM Rick Macklem wrote: > > 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 objec= ts? > > > > > > > > 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. > Oops, my mistake. It was the open(2) that failed with EOPNOTSUPP, not copy_file_range(2). (I have a simple test program that open(2)s file names and then uses copy_file_range(2) on the descriptors. Btw, an open(2) with O_PATH works, but no data is copied. Not sure if that should be considered correct behaviour? rick > rick > > > > > rick