Date: Wed, 20 Sep 2023 23:54:01 +0000 From: "John F Carr" <jfc@mit.edu> 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: <CABAD93F-E6B1-44A2-BD14-F3CC547EC7DA@mit.edu> 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 Sep 20, 2023, at 16:47, Rick Macklem <rick.macklem@gmail.com> wrote:
>=20
> 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)).
>=20
> Do you think copy_file_range(2) should work for shared memory objects?
>=20
> 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.
>=20
> rick
>=20
According to a Linux man page, some failure modes are
EINVAL Either fd_in or fd_out is not a regular file.
EOPNOTSUPP (since Linux 5.19) The filesystem does not support this o=
peration.
EXDEV (since Linux 5.19)
The files referred to by fd_in and fd_out are not on the
same filesystem, and the source and target filesystems are
not of the same type, or do not support cross-filesystem copy.
According to the FreeBSD man page
The copy_file_range() system call is expected to be compatible with th=
e
Linux system call of the same name.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABAD93F-E6B1-44A2-BD14-F3CC547EC7DA>