[PATCH] Add copy_file_range system call

[PATCH] Add copy_file_range system call

[Árni Dagur]

This patch was based on commit 53147f9, which added splice and vmsplice.
---
 The function signature in the glibc manpage specifies `loff_t` instead
 of `off_t`, for both `copy_file_range` and `splice`. In musl, however, 
 the function signature for `splice` specifies `off_t`, so I did the
 same here. I'm not an experienced C programmer, so that may have been
 wrong.

 include/unistd.h            | 1 +
 src/linux/copy_file_range.c | 8 ++++++++
 2 files changed, 9 insertions(+)
 create mode 100644 src/linux/copy_file_range.c

diff --git a/include/unistd.h b/include/unistd.h
index 9485da7a..00cc7042 100644
--- a/include/unistd.h
+++ b/include/unistd.h
@@ -188,6 +188,7 @@ char *get_current_dir_name(void);
 int syncfs(int);
 int euidaccess(const char *, int);
 int eaccess(const char *, int);
+ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
 #endif
 
 #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
diff --git a/src/linux/copy_file_range.c b/src/linux/copy_file_range.c
new file mode 100644
index 00000000..34742588
--- /dev/null
+++ b/src/linux/copy_file_range.c
@@ -0,0 +1,8 @@
+#define _GNU_SOURCE
+#include <fcntl.h>
+#include "syscall.h"
+
+ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags)
+{
+	return syscall(SYS_copy_file_range, fd_in, off_in, fd_out, off_out, len, flags);
+}
-- 
2.23.0

Re: [PATCH] Add copy_file_range system call

[Rich Felker]

On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote:
> This patch was based on commit 53147f9, which added splice and vmsplice.
> ---
>  The function signature in the glibc manpage specifies `loff_t` instead
>  of `off_t`, for both `copy_file_range` and `splice`. In musl, however, 
>  the function signature for `splice` specifies `off_t`, so I did the
>  same here. I'm not an experienced C programmer, so that may have been
>  wrong.

I think this looks ok. Regarding loff_t vs off_t, loff_t is the
kernel's API type for functions that take a 64-bit offset
unconditionally rather than glibc providing 32-bit off_t and 64-bit
off_t versions of them. This is gratuitous for musl where off_t is
always 64-bit. We provide loff_t as a macro that expands to off_t, but
even if it were a typedef the types woule be the same type, so it's
fine to use off_t here, and I think it's the cleanest and most
consistent with what we're doing elsewhere even if it's not textually
the same as the man page.

>  include/unistd.h            | 1 +
>  src/linux/copy_file_range.c | 8 ++++++++
>  2 files changed, 9 insertions(+)
>  create mode 100644 src/linux/copy_file_range.c
> 
> diff --git a/include/unistd.h b/include/unistd.h
> index 9485da7a..00cc7042 100644
> --- a/include/unistd.h
> +++ b/include/unistd.h
> @@ -188,6 +188,7 @@ char *get_current_dir_name(void);
>  int syncfs(int);
>  int euidaccess(const char *, int);
>  int eaccess(const char *, int);
> +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
>  #endif

Is there a reason for the choice to put it in unistd.h? Similar
functions seem to have gone in fcntl.h. unistd.h does not make the
loff_t type available which could be problematic to callers using it,
since they really should (for API compatibility) be declaring the
objects whose addresses they pass as loff_t.

If glibc does it here and exposes loff_t in unistd.h we might need to
consider doing that too with _GNU_SOURCE.

Rich

Re: [PATCH] Add copy_file_range system call

[Rich Felker]

On Mon, Aug 19, 2019 at 08:56:35PM -0400, Rich Felker wrote:
> On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote:
> > This patch was based on commit 53147f9, which added splice and vmsplice.
> > ---
> >  The function signature in the glibc manpage specifies `loff_t` instead
> >  of `off_t`, for both `copy_file_range` and `splice`. In musl, however, 
> >  the function signature for `splice` specifies `off_t`, so I did the
> >  same here. I'm not an experienced C programmer, so that may have been
> >  wrong.
> 
> I think this looks ok. Regarding loff_t vs off_t, loff_t is the
> kernel's API type for functions that take a 64-bit offset
> unconditionally rather than glibc providing 32-bit off_t and 64-bit
> off_t versions of them. This is gratuitous for musl where off_t is
> always 64-bit. We provide loff_t as a macro that expands to off_t, but
> even if it were a typedef the types woule be the same type, so it's
> fine to use off_t here, and I think it's the cleanest and most
> consistent with what we're doing elsewhere even if it's not textually
> the same as the man page.
> 
> >  include/unistd.h            | 1 +
> >  src/linux/copy_file_range.c | 8 ++++++++
> >  2 files changed, 9 insertions(+)
> >  create mode 100644 src/linux/copy_file_range.c
> > 
> > diff --git a/include/unistd.h b/include/unistd.h
> > index 9485da7a..00cc7042 100644
> > --- a/include/unistd.h
> > +++ b/include/unistd.h
> > @@ -188,6 +188,7 @@ char *get_current_dir_name(void);
> >  int syncfs(int);
> >  int euidaccess(const char *, int);
> >  int eaccess(const char *, int);
> > +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
> >  #endif
> 
> Is there a reason for the choice to put it in unistd.h? Similar
> functions seem to have gone in fcntl.h. unistd.h does not make the
> loff_t type available which could be problematic to callers using it,
> since they really should (for API compatibility) be declaring the
> objects whose addresses they pass as loff_t.
> 
> If glibc does it here and exposes loff_t in unistd.h we might need to
> consider doing that too with _GNU_SOURCE.

OK I went and looked at what glibc did (glibc commit
bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f) and they define the function
with arguments having type __off64_t and declare it in unistd.h. So I
think the expectation is that you use off_t with it (or off64_t if
doing the LFS dance on glibc with _FILE_OFFSET_BITS==32), loff_t is
not needed as part of the API to invoke it, and your patch looks fine.

Rich

Re: [PATCH] Add copy_file_range system call

[Ismael Luceno]

On 19/Aug/2019 20:56, Rich Felker wrote:
<...>
> Is there a reason for the choice to put it in unistd.h? Similar
> functions seem to have gone in fcntl.h. unistd.h does not make the
> loff_t type available which could be problematic to callers using it,
> since they really should (for API compatibility) be declaring the
> objects whose addresses they pass as loff_t.
> 
> If glibc does it here and exposes loff_t in unistd.h we might need to
> consider doing that too with _GNU_SOURCE.

+1. I've seen some code in the wild depend on loff_t.

Re: [PATCH] Add copy_file_range system call

[Rich Felker]

On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote:
> This patch was based on commit 53147f9, which added splice and vmsplice.
> ---
>  The function signature in the glibc manpage specifies `loff_t` instead
>  of `off_t`, for both `copy_file_range` and `splice`. In musl, however, 
>  the function signature for `splice` specifies `off_t`, so I did the
>  same here. I'm not an experienced C programmer, so that may have been
>  wrong.
> 
>  include/unistd.h            | 1 +
>  src/linux/copy_file_range.c | 8 ++++++++
>  2 files changed, 9 insertions(+)
>  create mode 100644 src/linux/copy_file_range.c
> 
> diff --git a/include/unistd.h b/include/unistd.h
> index 9485da7a..00cc7042 100644
> --- a/include/unistd.h
> +++ b/include/unistd.h
> @@ -188,6 +188,7 @@ char *get_current_dir_name(void);
>  int syncfs(int);
>  int euidaccess(const char *, int);
>  int eaccess(const char *, int);
> +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
>  #endif

Oh, one other detail I missed: the argument names here are not valid.
To be valid they'd need to be in the reserved namespace, but musl
policy is not to use them at all in prototypes. I can fix this when
applying, so no problem.

Rich

Re: [PATCH] Add copy_file_range system call

[Rich Felker]

On Mon, Aug 19, 2019 at 11:41:14PM +0000, Árni Dagur wrote:
> This patch was based on commit 53147f9, which added splice and vmsplice.
> ---
>  The function signature in the glibc manpage specifies `loff_t` instead
>  of `off_t`, for both `copy_file_range` and `splice`. In musl, however, 
>  the function signature for `splice` specifies `off_t`, so I did the
>  same here. I'm not an experienced C programmer, so that may have been
>  wrong.
> 
>  include/unistd.h            | 1 +
>  src/linux/copy_file_range.c | 8 ++++++++
>  2 files changed, 9 insertions(+)
>  create mode 100644 src/linux/copy_file_range.c
> 
> diff --git a/include/unistd.h b/include/unistd.h
> index 9485da7a..00cc7042 100644
> --- a/include/unistd.h
> +++ b/include/unistd.h
> @@ -188,6 +188,7 @@ char *get_current_dir_name(void);
>  int syncfs(int);
>  int euidaccess(const char *, int);
>  int eaccess(const char *, int);
> +ssize_t copy_file_range(int fd_in, off_t *off_in, int fd_out, off_t *off_out, size_t len, unsigned flags);
>  #endif
>  
>  #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
> diff --git a/src/linux/copy_file_range.c b/src/linux/copy_file_range.c
> new file mode 100644
> index 00000000..34742588
> --- /dev/null
> +++ b/src/linux/copy_file_range.c
> @@ -0,0 +1,8 @@
> +#define _GNU_SOURCE
> +#include <fcntl.h>
            ^^^^^^^^^

One more detail, this should be unistd.h. I'm fixing with applying it.

Rich