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]

Message-ID: <20171130044649.xfgwhd2wzdc5mwql@thunk.org>
Date:   Wed, 29 Nov 2017 23:46:49 -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 07:46:08PM -0600, Ashlie Martinez wrote:
> > 5.  Since I'm too lazy to wait 120 seconds, just force everything to disk:
> >
> >         sync
> 
> I believe you said in an earlier email that sync would erase any trace
> of the bug Amir found as it resolves the delayed allocation.

Right, but you're waiting 120 seconds, which is enough time that it
would resolve the delayed allocation.  So that's why I was trying to
replicate your Crashmonkey experiment.

And since you stated that you waited 120 seconds as the last step,
there should have been a barrier, and no I/O operations for
Crashmonkey to rearrange.  This is why I believe what I listed should
be exactly the same as your Crashmonkey test, if I understood it
correctly.

What you said was that you ran the following operations on the test
file:

1.      write 0x137dd 0xdc69 0x0
2.      fallocate 0xb531 0xb5ad 0x21446
3.      collapse_range 0x1c000 0x4000 0x21446
	<sleep 30>
4.      write 0x3e5ec 0x1a14 0x21446
5.      zero_range 0x20fac 0x6d9c 0x40000 keep_size
	<sleep 120>

So what was the block I/O trace?  What operations was crashmonkey
actually reordering?  There **really** shouldn't have been any....

Can you send the block I/O trace that was observed when you did the
following, a complete output of dumpe2fs on the file system, and a
debugfs stat output on the test file?

						- Ted

P.S.  I did read the Crashmonkey paper, so I'm aware of what
Crashmonkey does.  I'm just confused about your workload, since the
120 second sleep should have meant there was a barrier followed by
nothing else, making for a *very* boring crashmonkey replay.