bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] copy-file-range: work around Linux kernel bug


From: Pádraig Brady
Subject: Re: [PATCH] copy-file-range: work around Linux kernel bug
Date: Sun, 16 Jan 2022 13:37:30 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Thunderbird/95.0

On 15/01/2022 01:33, Paul Eggert wrote:
--- a/m4/copy-file-range.m4
+++ b/m4/copy-file-range.m4
@@ -7,6 +7,7 @@ dnl with or without modifications, as long as this notice is 
preserved.
  AC_DEFUN([gl_FUNC_COPY_FILE_RANGE],
  [
    AC_REQUIRE([gl_UNISTD_H_DEFAULTS])
+  AC_REQUIRE([AC_CANONICAL_HOST])
dnl Persuade glibc <unistd.h> to declare copy_file_range.
    AC_REQUIRE([AC_USE_SYSTEM_EXTENSIONS])
@@ -21,7 +22,7 @@ AC_DEFUN([gl_FUNC_COPY_FILE_RANGE],
         [AC_LANG_PROGRAM(
            [[#include <unistd.h>
            ]],
-          [[ssize_t (*func) (int, off_t *, int, off_t, size_t, unsigned)
+          [[ssize_t (*func) (int, off_t *, int, off_t *, size_t, unsigned)
                = copy_file_range;
              return func (0, 0, 0, 0, 0, 0) & 127;
            ]])
@@ -32,5 +33,27 @@ AC_DEFUN([gl_FUNC_COPY_FILE_RANGE],
if test "$gl_cv_func_copy_file_range" != yes; then
      HAVE_COPY_FILE_RANGE=0
+  else
+    AC_DEFINE([HAVE_COPY_FILE_RANGE], 1,
+      [Define to 1 if the function copy_file_range exists.])
+
+    case $host_os in
+      linux*)
+        AC_CACHE_CHECK([whether copy_file_range is known to work],
+          [gl_cv_copy_file_range_known_to_work],
+          [AC_COMPILE_IFELSE(
+             [AC_LANG_PROGRAM(
+                [[#include <linux/version.h>
+                ]],
+                [[#if LINUX_VERSION_CODE < KERNEL_VERSION (5, 3, 0)
+                   #error "copy_file_range is buggy"
+                  #endif
+                ]])],
+             [gl_cv_copy_file_range_known_to_work=yes],
+             [gl_cv_copy_file_range_known_to_work=no])])
+        if test "$gl_cv_copy_file_range_known_to_work" = no; then
+          REPLACE_COPY_FILE_RANGE=1
+        fi;;
+    esac
    fi
  ])

This looks like the replacement will only be used when the build system uses an 
older kernel?
If so this seems brittle. Consider the case where el7 rpms are being built on
central build systems with newer kernels.

cheers,
Pádraig



reply via email to

[Prev in Thread] Current Thread [Next in Thread]