From nobody Wed Sep 20 23:09:32 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 4RrZ4952xdz4vJHy for ; Wed, 20 Sep 2023 23:09:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4RrZ490FB6z4ZSj; Wed, 20 Sep 2023 23:09:45 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-573e67cc6eeso213703a12.2; Wed, 20 Sep 2023 16:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695251383; x=1695856183; 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=FQgIHE/BazvVrD593xmbwHiUmvGF5COmSUirKDGcsFw=; b=YQHFaQgDyvvYl8LvdCQrNrZuLUOPRkv4dwciSqXXcEYFOSwS28CTGLHuSFV/n/bMvZ 2bDe+hQQl+lHkBirYGkZDx7XmZxp6X/hgbjtTofoXAIXe02C8OceOletVji8xV1Eb8JZ wLjdGwu3uy89WLqoaQOjeufYh8zsbUkP8V7d3fYXmIp/QwyvplT5da7dfXqHITePlHcH c6SHhwLQCCviyaCKfyDEvyH+/Hwq1XWCSb6Kp9f5+pHXW+UBvVFaCzLPJaVAnOOuxk9O Ue4UcGgNOqYjS14g+0Nxl2PRjvk+zlo92NvfwIJy4Y0TGe/z5EaEIb/PaaEgef4+sCxL i7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695251383; x=1695856183; 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=FQgIHE/BazvVrD593xmbwHiUmvGF5COmSUirKDGcsFw=; b=IKQexeoghh6Dtpg0GSRQ+PkhQT2Ly0tYkaLomTH3fUGP91rWILz8X3BPSdD6lD52rK 3TEzyedrPCeii/nP5RDf0c4yuqvc1U4TclEAgIuJqGDKRKcntgip2l60nmJ8THbHlhyp 9d+/hmcEkGPyWy2uU7hZRgoCqxQMw7WPfnXMhc2fx0h2tNFCfg5hTbFFloGhu5Bn+cTv l9rPSQVZabj9q0s+FLJwZevcjsBrgOpSfe2CtheC8ogs7p/GBMGA/3Wme7lVyjo+SY8E EBXrxS3n+EDbTsHyq4jvIFFmdIQllqn/Iv52MoMi9aOMZ1UYlFslEnXM1/902hP/6UbG lqHw== X-Gm-Message-State: AOJu0YzrLoX9U1WUgIdCSt3lymXL9rwRaZ/J7coR5cbG27UDq5bCEGip xwujaxAYuQX9hGYo4INKW5Cn3M59y5EkvsKlAlJdPn4= X-Google-Smtp-Source: AGHT+IFQcTeIRKfLzJflj8rmdtxyexw20dDYUeWfyuNu/2C1Wz6poYi0dEW9f94Y/engv0fGO5fdY+Hc8ecvTdfPKyk= X-Received: by 2002:a05:6a20:5494:b0:13d:8876:4c97 with SMTP id i20-20020a056a20549400b0013d88764c97mr4325670pzk.16.1695251383334; Wed, 20 Sep 2023 16:09:43 -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:09:32 -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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Queue-Id: 4RrZ490FB6z4ZSj On Wed, Sep 20, 2023 at 3:07=E2=80=AFPM Alan Somers w= rote: > > 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?) rick