Bug 504676 - gfs2: extending direct IO writes expose stale data (corruption)
Summary: gfs2: extending direct IO writes expose stale data (corruption)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Steve Whitehouse
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-08 18:56 UTC by Eric Sandeen
Modified: 2009-09-02 09:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 09:02:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Guesstimate fix (367 bytes, patch)
2009-06-09 08:51 UTC, Steve Whitehouse
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 08:53:34 UTC

Description Eric Sandeen 2009-06-08 18:56:47 UTC
The xfstests test suite found this one.

On a local gfs2 filesystem, on kernel-2.6.18-149.el5:

xfs_io -F -f -d -t -c "pwrite -S 0x63 0 65536"     \
                   -c "truncate 1" \
                   -c "pwrite -S 0x41 65536 65536" \
                   -c "pread -v 0 131072" \
                   /mnt/scratch/tryit

This will write a "0x63" pattern from 0 to 65536, truncate to 1 byte, write a "0x41" pattern from 65536->131072, and then read back the entire file - all with O_DIRECT.

We should get 0s from byte 1 through byte 65536; on gfs2 we get the old data (0x63):

# dd if=/mnt/scratch/tryit iflag=direct | hexdump -C
00000000  63 63 63 63 63 63 63 63  63 63 63 63 63 63 63 63  |cccccccccccccccc|
*
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
*
00020000

A buffered read gets what we expect:

# dd if=/mnt/scratch/tryit | hexdump -C
00000000  63 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |c...............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
*
00020000


Confirmed upstream as well.

-Eric

Comment 1 Steve Whitehouse 2009-06-09 08:51:33 UTC
Created attachment 346988 [details]
Guesstimate fix

Does this fix the issue?

Comment 2 Steve Whitehouse 2009-06-10 12:33:12 UTC
The patch in comment #1 is now in upstream. The fix is trivial and we should try and do this for 5.4

Comment 3 RHEL Program Management 2009-06-10 12:51:21 UTC
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
release.

Comment 4 Steve Whitehouse 2009-06-11 15:01:18 UTC
Also tested on RHEL as well as upstream now.

Comment 5 Don Zickus 2009-06-30 20:22:41 UTC
in kernel-2.6.18-156.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 8 errata-xmlrpc 2009-09-02 09:02:45 UTC
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.

http://rhn.redhat.com/errata/RHSA-2009-1243.html


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