Description of problem: On aarch64, valgrind whines about an ioctl invocation in cp(1). Perhaps this is a bug in cp, but I think it more likely that valgrind needs to understand ioctl calls better. I don't see a comparable complaint on x86_64. Version-Release number of selected component (if applicable): valgrind-3.16.1-11.fc33.aarch64 coreutils-8.32-12.fc33.aarch64 How reproducible: 100% Steps to Reproduce: 1. touch foo 2. valgrind cp foo bar Actual results: ==63743== Memcheck, a memory error detector ==63743== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==63743== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==63743== Command: cp foo bar ==63743== ==63743== Syscall param ioctl(generic) points to unaddressable byte(s) ==63743== at 0x49DC550: ioctl (ioctl.S:26) ==63743== by 0x116D97: UnknownInlinedFun (copy.c:371) ==63743== by 0x116D97: copy_reg (copy.c:1239) ==63743== by 0x1193A7: copy_internal.constprop.0 (copy.c:2716) ==63743== by 0x11A80B: copy.constprop.0 (copy.c:3024) ==63743== by 0x11AC5F: do_copy (cp.c:780) ==63743== by 0x10C513: main (cp.c:1232) ==63743== Address 0x3 is not stack'd, malloc'd or (recently) free'd Expected results: No complaint Additional info: I installed coreutils' debuginfo to get the above trace, otherwise it's mostly numeric.
This comes from GNU coreutils copy.c: /* Perform the O(1) btrfs clone operation, if possible. Upon success, return 0. Otherwise, return -1 and set errno. */ static inline int clone_file (int dest_fd, int src_fd) { #ifdef FICLONE return ioctl (dest_fd, FICLONE, src_fd); #else (void) dest_fd; (void) src_fd; errno = ENOTSUP; return -1; #endif } valgrind doesn't know what FICLONE is. This is upstream bug https://bugs.kde.org/show_bug.cgi?id=397605 which comes with a patch. Will investigate to see if it can be applied upstream and backported.
Oh, interesting, so that implies that it's not so much arch-specific as filesystem-specific. But both the Fedora 33 machine I see this on and the RHEL8.3 x86_64 machine I don't see it on are running xfs. Both define FICLONE in /usr/include/linux/fs.h. So I'm still confused. Is this a very recent change in coreutils?
(In reply to Tom Lane from comment #2) > Oh, interesting, so that implies that it's not so much arch-specific as > filesystem-specific. But both the Fedora 33 machine I see this on and the > RHEL8.3 x86_64 machine I don't see it on are running xfs. Both define > FICLONE in /usr/include/linux/fs.h. So I'm still confused. Is this a very > recent change in coreutils? I am not sure why it now suddenly shows up, but I could replicate it and I believe the patch is correct so I have added it upstream and to the rawhide valgrind package.