From: Dave Chinner <david@fromorbit.com>
To: Jan Tulak <jtulak@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [RFC PATCH] xfstests: Add mkfs input validation tests
Date: Fri, 29 Apr 2016 11:59:27 +1000 [thread overview]
Message-ID: <20160429015927.GN18496@dastard> (raw)
In-Reply-To: <1461832149-18276-1-git-send-email-jtulak@redhat.com>
On Thu, Apr 28, 2016 at 10:29:09AM +0200, Jan Tulak wrote:
> Test inputs for my mkfs-cleaning patchset. This test will fail with the old sphageti code mkfs, among others because the old code accepts incorrect values.
>
>
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
Please don't strip the commit messages from patches you've picked up
from other people - it loses valuable information, as well as the
original author of the code. i.e. The original commit message was:
From: Dave Chinner <dchinner@redhat.com>
mkfs.xfs does not do a very good job of input validation. This test
is designed to exercise the input validation and test good/bad
combinations of options being set. It will not pass on a current
mkfs.xfs binary - it is designed to be the test case for a input
validation cleanup.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>
> Hi guys,
>
> I'm sending this patch although the mentioned patchset is not yet merged.
> It might help you a bit with checking if there are any issues with
> the patchset, as here it is clear, what options works and what not.
in which case, a "_require_xfs_mkfs_validation" rule should be
written to determine the version of mkfs being. e.g. by testing one
of the failure cases that the unfixed binary says is ok.
....
> +# basic "should fail" options
> +# logarithm based options are no longer valid
> +# NOTE: umm, when it got invalid? It seems to be still supported...
> +#do_mkfs_fail -s log=10 $SCRATCH_DEV
> +#do_mkfs_fail -b log=10 $SCRATCH_DEV
> +#do_mkfs_fail -n log=10 $SCRATCH_DEV
> +#do_mkfs_fail -i log=10 $SCRATCH_DEV
> +#do_mkfs_fail -d sectlog=10 $SCRATCH_DEV
> +#do_mkfs_fail -l sectlog=10 $SCRATCH_DEV
They were expected to fail because I was going to remove the log
options from mkfs as part of the cleanup series because they are
redundant and nobody uses them. i.e this test was written with what
I wanted as the end result of the mkfs input validation cleanup, not
an iteration of the current behaviour.
After all the data section tests, the new tests you've added all
seem to be pretty ad-hoc. What I was fleshing out in this test was
a relatively complete set exercising each the different options mkfs
supports.
I'd only iterated data section options so far in this test. I'd just
started on the naming section tests, and had not added any but a
basic test. That needs to be iterated, as do the inode, log (both
internal and external), metadata and realtime options....
> +# invalid file section tests
> +rm -f $fsimg
> +$XFS_IO_PROG -f -c "truncate $fssize" $fsimg
> +do_mkfs_fail -d file $fsimg
> +do_mkfs_fail -d file,name=$fsimg
Why should these fail - size should not be required if the image
file already exists and is of sufficient size....
> +
> +# naming section tests
> +do_mkfs_pass -n size=65536 $SCRATCH_DEV
> +
> +# boolean options
> +$XFS_IO_PROG -f -c "truncate $fssize" $fsimg
> +do_mkfs_pass -d file=1,size=$fssize $fsimg
> +do_mkfs_pass -d file=0 $SCRATCH_DEV
> +do_mkfs_fail -d file=1 $SCRATCH_DEV
More image file tests, belong in the data section with the other
image file tests.
> +# Specific flag combinations where some bug appeared during development,
> +# to catch the same issue if it re-appears. If there are multiple similar
> +# checks, move them to a standalone block.
> +
> +
> +do_mkfs_pass -m crc=1,finobt=1 $SCRATCH_DEV
What about all the other invalid cases?
> +do_mkfs_pass -m crc=1 -n ftype=1 $SCRATCH_DEV
> +do_mkfs_pass -m crc=0 -n ftype=1 $SCRATCH_DEV
> +do_mkfs_fail -m crc=1 -n ftype=0 $SCRATCH_DEV
> +do_mkfs_pass -m crc=0 -n ftype=0 $SCRATCH_DEV
> +do_mkfs_pass -n ftype=1 -m crc=0 $SCRATCH_DEV
One of the cleanup requirements was that option parsing would not
be order sensitive, so I don't think you need to iterate parameters
in different orders. That would just blow out the test matrix
unnecessarily. Also, if you really need to repeat the same test but
with different orders, please place those tests sequentially in the
file so it's clear that they are duplicate/order swapped tests....
> +# if user states crc=0,finobt=1, fail instead of warning
> +do_mkfs_fail -m crc=0,finobt=1 $SCRATCH_DEV
Why is this separate to the other crc,finobt test? Please try to
keep the parameter checks in logical groupings....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-04-29 1:59 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-21 9:39 [PATCH 00/19 v2] mkfs cleaning Jan Tulak
2016-04-21 9:39 ` [PATCH 01/19] xfsprogs: use common code for multi-disk detection Jan Tulak
2016-04-21 9:39 ` [PATCH 02/19] mkfs: sanitise ftype parameter values Jan Tulak
2016-04-21 9:39 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros Jan Tulak
2016-05-02 23:06 ` Eric Sandeen
2016-05-04 0:48 ` Eric Sandeen
2016-04-21 9:39 ` [PATCH 04/19] mkfs: validate all input values Jan Tulak
2016-04-21 9:39 ` [PATCH 05/19] mkfs: factor boolean option parsing Jan Tulak
2016-04-21 9:39 ` [PATCH 06/19] mkfs: validate logarithmic parameters sanely Jan Tulak
2016-04-21 9:39 ` [PATCH 07/19] mkfs: structify input parameter passing Jan Tulak
2016-04-21 9:39 ` [PATCH 08/19] mkfs: getbool is redundant Jan Tulak
2016-05-02 23:08 ` Eric Sandeen
2016-04-21 9:39 ` [PATCH 09/19] mkfs: use getnum_checked for all ranged parameters Jan Tulak
2016-04-21 9:39 ` [PATCH 10/19] mkfs: add respecification detection to generic parsing Jan Tulak
2016-04-21 9:39 ` [PATCH 11/19] mkfs: table based parsing for converted parameters Jan Tulak
2016-05-02 23:09 ` Eric Sandeen
2016-04-21 9:39 ` [PATCH 12/19] mkfs: merge getnum Jan Tulak
2016-04-21 9:39 ` [PATCH 13/19] mkfs: encode conflicts into parsing table Jan Tulak
2016-05-02 23:11 ` Eric Sandeen
2016-05-03 23:39 ` Eric Sandeen
2016-05-04 0:47 ` Eric Sandeen
2016-04-21 9:39 ` [PATCH 14/19] mkfs: add string options to generic parsing Jan Tulak
2016-05-02 23:11 ` Eric Sandeen
2016-04-21 9:39 ` [PATCH 15/19] mkfs: don't treat files as though they are block devices Jan Tulak
2016-04-21 12:43 ` Jan Tulak
2016-04-21 20:13 ` Eric Sandeen
2016-04-22 7:46 ` Jan Tulak
2016-04-22 7:49 ` [PATCH 15/19 v2] " Jan Tulak
2016-04-29 14:47 ` [PATCH 15/19 v3] " Jan Tulak
2016-04-29 19:11 ` Eric Sandeen
2016-05-03 9:59 ` Jan Tulak
2016-05-02 23:13 ` [PATCH 15/19] " Eric Sandeen
2016-04-21 9:39 ` [PATCH 16/19] mkfs: move spinodes crc check Jan Tulak
2016-04-21 9:39 ` [PATCH 17/19] mkfs: unit conversions are case insensitive Jan Tulak
2016-04-21 9:39 ` [PATCH 18/19] mkfs: add optional 'reason' for illegal_option Jan Tulak
2016-04-21 9:39 ` [PATCH 19/19] mkfs: conflicting values with disabled crc should fail Jan Tulak
2016-04-28 8:29 ` [RFC PATCH] xfstests: Add mkfs input validation tests Jan Tulak
2016-04-29 1:59 ` Dave Chinner [this message]
2016-04-29 14:42 ` Jan Tulak
2016-05-02 23:05 ` [PATCH 00/19 v2] mkfs cleaning Eric Sandeen
2016-05-10 6:10 ` Dave Chinner
2016-06-01 13:19 ` Jan Tulak
2016-06-03 0:53 ` Dave Chinner
2016-06-03 9:20 ` Jan Tulak
2016-06-03 12:09 ` Jan Tulak
2016-06-04 0:32 ` Dave Chinner
2016-06-06 7:42 ` Jan Tulak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160429015927.GN18496@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=jtulak@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox