Bug 500693 - LTP ftest04 and ftest08 Failures
LTP ftest04 and ftest08 Failures
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Cong Wang
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2009-05-13 13:51 EDT by CAI Qian
Modified: 2013-09-29 22:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 04:38:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
simpler reproducer (5.22 KB, text/plain)
2009-05-13 13:51 EDT, CAI Qian
no flags Details

  None (edit)
Description CAI Qian 2009-05-13 13:51:37 EDT
Created attachment 343828 [details]
simpler reproducer

Description of problem:
Those tests are forking several processes to do a random lseek each, and
read/write a chunk of data to the same file.

The failure messages are like the following,

# ./ftest04
ftest04     1  FAIL  :  Test[1]: xfr=1920 != 2048, zero read.
ftest04     1  FAIL  :  Expected 0 exit status - failed.
ftest04     2  FAIL  :  Test failed.

This is because one of children is doing,

lseek64(fd, 534528);

readv(fd, buf[2048/16], 16);

but readv() only returns less than 16 chunks of data. If I replace the
above call with,

read(fd, buf, 2048);

It seems work just fine.

I can always reproduce this on at least 2 x86-64 machines with both
-128.el5 and -141.el5 kernels.
- bigisis.rhts.bos.redhat.com
- gs-bl460cg1-01.rhts.bos.redhat.com

In additions, upstream kernel seems not affected by this by running the
simpler reproducer attached more than 7000 times.
# uname -a
Linux nec-em18.rhts.bos.redhat.com #1 SMP Tue
Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q glibc

Version-Release number of selected component (if applicable):
# rpm -q glibc

How reproducible:
Usually failed within 200 times by running the simpler reproducer in a loop.

Steps to Reproduce:
1. gcc readv.c -o readv
2. t=1; while :; do t=$((t + 1)); ./readv; if [ $? -ne 0 ]; then break; fi; echo $t; done
Actual results:
Test[3]: xfr=640 != 2048, zero read.
Expected 0 exit status - failed.
Test failed.

Expected results:
Always pass.

Additional information:
This does not look like 64-bit only problem, because after compiled the simpler reproducer using,
gcc -m32 readv.c -o readv

It can reproduce the same problem.
Comment 3 RHEL Product and Program Management 2009-07-02 13:43:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 5 Don Zickus 2009-07-07 11:05:03 EDT
in kernel-2.6.18-157.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 9 errata-xmlrpc 2009-09-02 04:38:30 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.