Date: Wed, 20 Sep 2023 15:07:45 -0700 From: Alan Somers <asomers@freebsd.org> To: Rick Macklem <rick.macklem@gmail.com> Cc: Freebsd fs <freebsd-fs@freebsd.org> Subject: Re: RFC: Should copy_file_range(2) work for shared memory objects? Message-ID: <CAOtMX2jojm01Xx9rfOdPmevWb8TasJ27U5u6GT3n3NiWwYwYoQ@mail.gmail.com> In-Reply-To: <CAM5tNy4HxY8LK0f6baGhu=opoC3-4ODhqNyxoyPY8vdwxGs5Xg@mail.gmail.com> References: <CAM5tNy4HxY8LK0f6baGhu=opoC3-4ODhqNyxoyPY8vdwxGs5Xg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 20, 2023 at 3:05=E2=80=AFPM Rick Macklem <rick.macklem@gmail.co= m> 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jojm01Xx9rfOdPmevWb8TasJ27U5u6GT3n3NiWwYwYoQ>