linux-ext4 - Re: [PATCH v2] xfstests: add a new test case for ext4 indirect-based file

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: <51494B26.6020204@sandeen.net>
Date:	Wed, 20 Mar 2013 00:37:42 -0500
From:	Eric Sandeen <sandeen@...deen.net>
To:	xfs@....sgi.com, linux-ext4@...r.kernel.org,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [PATCH v2] xfstests: add a new test case for ext4 indirect-based
 file

On 3/20/13 12:45 AM, Zheng Liu wrote:
>>> +f6aeca13ec49e5b266cd1c913cd726e3
>>> > > +	12. unwritten -> data -> unwritten
>> > 
>> > It's a little odd that the output contains "unwritten" when this test
>> > is explicitly for testing *without* unwritten extents.  Should this be
>> > cleaned up a little in common.punch, maybe?
> I will try to define a new function called _test_indirect_punch() to
> test punching hole without unwritten extent.

It's just the helper which prints "unwritten" regardless of what
is passed as "$alloc_cmd" to _test_generic_punch, right... so there's
nothing wrong with the test, really - it's just odd output.

I'm not sure it's worth a big copy & paste just to change
the output text, but if you can think of something simple to clean
it up, it might be worth it.

-Eric
--
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