lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 23 Feb 2012 09:15:19 -0600
From:	Eric Sandeen <>
To:	Philipp Hahn <>
CC:	"Ted Ts'o" <>,
	ext4 development <>,
Subject: Re: backport "ext4: serialize unaligned asynchronous DIO" to 2.6.32

Hash: SHA1

On 2/23/12 7:23 AM, Philipp Hahn wrote:
> Hello Ted, hello Eric,
> On Monday February 7th 2011 16:59:36 Ted Ts'o wrote:
>> commit 7520bb0f2980ef79d17dcbec2783760b37490ffc

upstream is actually e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d but you probably knew that.

>> Author: Eric Sandeen <>
>> Date:   Mon Feb 7 10:57:28 2011 -0500
>>     ext4: serialize unaligned asynchronous DIO
>>     ext4 has a data corruption case when doing non-block-aligned
>>     asynchronous direct IO into a sparse file, as demonstrated
>>     by xfstest 240.
> I hope you remember that bug, because I encountered this data corruption bug 
> on Debians 2.6.32(.51) kernel as well.

I remember it well ;)

I also backported it to RHEL6, but that "2.6.32" kernel also had a few of ext4 updates.

Still, grabbing a centos6 kernel src.rpm and looking might help you.

FWIW I also backported f46c483357c2d87606bbefb511321e3efd4baae0 and
f2d28a2ebcb525a6ec7e2152106ddb385ef52b73 as helpers.

> On the other hand RedHat seems to have back-ported that fix to RHEL5 (2.6.18)  
> and probably RHEL6 (2.6.32) as well, but I don't have a subscription, so I 
> can't verify that:
> <>
> <>

615309 is the RHEL6 bug.  Sadly it's marked private.

> The Xen-people also encountered it and asked for someone to backport it:
> <>
> I tried to backport it from 2.6.38~rc5 to and thus far it seems to 
> fix the bug. But several other things were re-named and re-organized between 
> those versions, so it was not slreight forward.
> Since I'm no ext4 expert, I'd like to ask you to have a look at this backport. 
> Is it sound or are there some tests I can throw at it to get it tested more 
> thoroughly?

xfstests test #240 tests it specifically:

# FS QA Test No. 240
# Test that non-block-aligned aio+dio into holes does not leave
# zero'd out portions of the file
# QEMU IO to a file-backed device with misaligned partitions
# can send this sort of IO
# This test need only be run in the case where the logical block size
# of the device can be smaller than the file system block size.

and running all the xfstests over your result would probably be good.

FWIW, there was a related xfs fix as well:

that one's not marked private <eyeroll>

> Does is classify for <>?

probably so.

To be honest I am really pressed for time right now, and this was somewhat tricky code.  I won't be able to review it right now, anyway, but can try to get to it at some point if my schedule lightens up... :(

- -Eric

> Thanks in advance
> Philipp Hahn

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists