Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1346070

Summary: armv7hl: pwritev system call passes incorrect offset to kernel, always returns -EFBIG
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: adhemerval.zanella, amit.shah, arjun.is, berrange, cfergeau, codonell, dj, dwmw2, fweimer, itamar, jakub, law, mfabian, pbonzini, pfrankli, rjones, siddhesh, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: armv7hl   
OS: Unspecified   
Whiteboard:
Fixed In Version: glibc-2.23.90-24.fc25 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-05 16:39:26 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:
Bug Depends On:    
Bug Blocks: 910269    
Attachments:
Description Flags
pwritev-test.c none

Description Richard W.M. Jones 2016-06-13 20:22:31 UTC 
Description of problem:

Note: This is on armv7hl only.

Simple qemu-img commands fail with odd errors, eg:

$ qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
qemu-img: blank-disk-1s.qcow2: The image size is too large for file format 'qcow2' (try using a larger cluster size)
Formatting 'blank-disk-1s.qcow2', fmt=qcow2 size=512 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16

$ qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1K.qcow2 1K
qemu-img: blank-disk-1K.qcow2: The image size is too large for file format 'qcow2' (try using a larger cluster size)
Formatting 'blank-disk-1K.qcow2', fmt=qcow2 size=1024 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16

Version-Release number of selected component (if applicable):

qemu 2:2.6.0-3.fc25

How reproducible:

Unknown, but at least once.

Steps to Reproduce:
1. See commands above.
Comment 1 Richard W.M. Jones 2016-06-13 21:46:06 UTC 
Weirdly this does *not* happen with qemu 2:2.6.0-3.fc24.
The only apparent difference is F24 vs F25 (so glibc? kernel?)

I can reproduce this in upstream qemu on Rawhide/armv7l.
Comment 2 Richard W.M. Jones 2016-06-14 11:13:38 UTC 
Created attachment 1167837 [details]
pwritev-test.c

Please try the attached program with glibc-2.23.90-21.fc25.armv7hl

$ gcc -Wall pwritev-test.c -o pwritev-test
$ ./pwritev-test 
pwritev: File too large

It works on x86-64, and it also works on armv7 in Fedora 24.

The reason is because glibc is mangling (byte swapping, I think?)
the 'offset' parameter.  I passed offset = 32, but:

$ strace ./pwritev-test 
...
pwritev(3, [{"\0\0\0\0\0\0\0\0\0\0", 10}, {"\0\0\0\0\0\0", 6}], 2, 137438953472) = -1 EFBIG (File too large)

where 137438953472 == 0x2000000000
Comment 3 Carlos O'Donell 2016-06-14 17:26:25 UTC 
Might be caused by this.

commit af5fdf5a358329161cc3960f5e54fac16dbb8063
Author: Adhemerval Zanella <adhemerval.zanella>
Date:   Mon Apr 11 15:07:12 2016 -0300

    Consolidate pwritev/pwritev64 implementations
    
    This patch consolidates all the pwritev{64} implementation for Linux
    in only one (sysdeps/unix/sysv/linux/pwritev{64}.c).  It also removes the
    syscall from the auto-generation using assembly macros.
    
    It was based on previous pwrite/pwrite64 consolidation patch.  The new macro
    SYSCALL_LL{64} is used to handle the offset argument and alias is created
    for __ASSUME_OFF_DIFF_OFF64 in case of pread64.
    
    Checked on x86_64, i386, aarch64, and powerpc64le.
Comment 4 Adhemerval Zanella 2016-06-14 23:48:46 UTC 
I sent a fix for this issue for review [1].

[1] https://sourceware.org/ml/libc-alpha/2016-06/msg00559.html