Bug 1909447

Summary:	valgrind complains about ioctl call in cp on aarch64
Product:	[Fedora] Fedora	Reporter:	Tom Lane <tgl>
Component:	valgrind	Assignee:	Mark Wielaard <mjw>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	dodji, jakub, mjw
Target Milestone:	---
Target Release:	---
Hardware:	aarch64
OS:	Unspecified
Whiteboard:
Fixed In Version:	valgrind-3.16.1-12.fc34	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-12-20 21:16:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Lane 2020-12-20 03:08:58 UTC

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.

Comment 1 Mark Wielaard 2020-12-20 13:32:49 UTC

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.

Comment 2 Tom Lane 2020-12-20 16:11:47 UTC

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?

Comment 3 Mark Wielaard 2020-12-20 21:16:29 UTC

(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.