linux-ext4 - Re: ext4 fix for interaction between i_size, fallocate, and delalloc after a crash

lists.openwall.net		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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 29 Nov 2017 19:48:16 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Ashlie Martinez <ashmrtn@...xas.edu>
Cc:     Amir Goldstein <amir73il@...il.com>,
        Vijay Chidambaram <vvijay03@...il.com>,
        Ext4 <linux-ext4@...r.kernel.org>
Subject: Re: ext4 fix for interaction between i_size, fallocate, and delalloc
 after a crash

On Wed, Nov 29, 2017 at 01:58:53PM -0600, Ashlie Martinez wrote:
> Ted,
> 
> 1.      write 0x137dd 0xdc69 0x0
> 2.      fallocate 0xb531 0xb5ad 0x21446
> 3.      collapse_range 0x1c000 0x4000 0x21446
> 4.      write 0x3e5ec 0x1a14 0x21446
> 5.      zero_range 0x20fac 0x6d9c 0x40000 keep_size
> 
> I have made a CrashMonkey test that runs the same operations run by
> xfstests generic/456 as I wanted a bit more control over the test. My
> test runs operations 1-3 from the list above, and then runs sleep(30).
> After that, it runs operations 4 and 5 (I skipped operation 6 as it
> doesn't seem to be related to the underlying cause of the bug).
> CrashMonkey then waits a further 120 seconds for IO to trickle down to
> the block device.

So I'm not sure exactly what Crashmonkey is doing here.  Are you
forcing a crash, or not?

So here's my test which I think should replicate what you are doing.

1.  Start "kvm-xfstests shell"
2.  Create the fsxops file:

	cat > /tmp/fsxops
	write 0x137dd 0xdc69 0x0
	fallocate 0xb531 0xb5ad 0x21446
	collapse_range 0x1c000 0x4000 0x21446
	write 0x3e5ec 0x1a14 0x21446
	zero_range 0x20fac 0x6d9c 0x40000 keep_size
	<type control-d>

3.  Create a scratch file system and mount it:

	mke2fs -Fq -t ext4 /dev/vdc
	mount /vdc

4.  Run fsx:

	./xfstests/ltp/fsx -d --replay-ops /tmp/fsxops /vdc/testfile

5.  Since I'm too lazy to wait 120 seconds, just force everything to disk:

	sync

6a.  Unmount the file system and check it:

	umount /vdc
	e2fsck -fy /dev/vdc

6b.   Force a crash, and then restart kvm-xfstests shell, and then check the file system:

	<type control-A followed by 'x'>
	kvm-xfstests shell
	e2fsck -fy /dev/vdc

In both cases, e2fsck does not complain.  In the 6b variant, e2fsck
will replay the journal first, but other than that, no real differences.

So, tell me --- how is what I am doing any different from your Crashmonkey test?

    	    	       	      - Ted