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:	Mon, 23 Feb 2015 15:11:34 -0800
From:	Omar Sandoval <osandov@...ndov.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	fstests@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: add regression tests for ^extents punch hole

On Tue, Feb 24, 2015 at 09:46:20AM +1100, Dave Chinner wrote:
> On Mon, Feb 23, 2015 at 02:39:36PM -0800, Omar Sandoval wrote:
> > Linux commit 6f30b7e37a82 (ext4: fix indirect punch hole corruption)
> > fixes several bugs in the FALLOC_FL_PUNCH_HOLE implementation for an
> > ext4 filesystem with indirect blocks.
> > 
> > Signed-off-by: Omar Sandoval <osandov@...ndov.com>
> > ---
> >  tests/ext4/005     | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  tests/ext4/005.out |  29 ++++++++++++++
> >  tests/ext4/group   |   1 +
> >  3 files changed, 145 insertions(+)
> >  create mode 100755 tests/ext4/005
> >  create mode 100644 tests/ext4/005.out
> 
> What's ext4 specific about this test apart from the mkfs parameter?
> Shouldn't it be generic and so test all the filesystems behave the
> same?  i.e. when someone then runs
> 
> # MKFS_OPTIONS="-b size=1k -O ^extents" ./check -g auto
> 
> That will exercise this specific regression fix, not to mention give
> much, much better test coverage of that configuration than just
> making a single test use that config...
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@...morbit.com

Hi, Dave,

This test isn't completely generic bcause the output is dependent on the
block size. In particular, fpunch+fiemap will have different results
based on the block size:

----
# mkfs.ext3 -b1024 /dev/sdb1
# mount /dev/sdb1 /mnt/test
# xfs_io -f -c 'pwrite 0 8192' /mnt/test/a
# xfs_io -c 'fpunch 0 1024' /mnt/test/a
# xfs_io -c fiemap /mnt/test/a
/mnt/test/a:
        0: [0..1]: hole
        1: [2..15]: 1028..1041
# umount /mnt/test
# mkfs.ext3 -b4096 /dev/sdb1
# mount /dev/sdb1 /mnt/test
# xfs_io -f -c 'pwrite 0 8192' /mnt/test/a
# xfs_io -c 'fpunch 0 1024' /mnt/test/a
# xfs_io -c fiemap /mnt/test/a
/mnt/test/a:
        0: [0..15]: 8192..8207
----

I could either remove the fiemap output from the test case and rely on
the md5sum or round all of the punches to some larger block size so it
will behave the same up to, say, 8k. Do either of those options sound
better?

Alternatively, is there a good way to have block size-dependent test
output? Then we could have the test adapt to different block sizes and
cover these regressions at any block size, not just 1k.

Thanks!
-- 
Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ