From: Dave Chinner <david@fromorbit.com>
To: Anand Jain <anand.jain@oracle.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] fstests: btrfs: testcase for sysfs policy syntax verification
Date: Tue, 4 Feb 2025 11:18:13 +1100 [thread overview]
Message-ID: <Z6FcxffA-v4-01lI@dread.disaster.area> (raw)
In-Reply-To: <fa76f7ed-06e3-4f16-a762-fa444226bcdf@oracle.com>
On Fri, Jan 31, 2025 at 02:43:03PM +0800, Anand Jain wrote:
>
> > > +set_sysfs_policy_must_fail()
> > > +{
> > > + local attr=$1
> > > + shift
> > > + local policy=$@
> > > +
> > > + _set_fs_sysfs_attr $SCRATCH_DEV $attr ${policy} | _filter_sysfs_error \
> > > + | _expect_error_invalid_argument | tee -a $seqres.full
> >
> > This "catch an exact error or output a different error then use
> > golden image match failure on secondary error to mark the test as
> > failed" semantic is .... overly complex.
> >
> > The output on failure of _filter_sysfs_error will be "Invalid
> > input". If there's some other failure or it succeeds, the output
> > will indicate the failure that occurred (i.e. missing line means no
> > error, different error will output directly by the filter). The
> > golden image matching will still fail the test.
> >
> > IOWs, _expect_error_invalid_argument and the output to seqres.full
> > can go away if the test.out file has a matching error for each
> > call to set_sysfs_policy_must_fail(). i.e it looks like:
> >
> > QA output created by 329
> > Invalid input
> > Invalid input
> > Invalid input
> > Invalid input
> > Invalid input
> > Invalid input
> > .....
> > Invalid input
>
> Thanks for the review.
>
> This test case verifies the sysfs interface syntax in general.
> Relying on golden output can cause false negatives on older
> kernels lacking support for newer sysfs policies.
> Creating individual test cases for each sysfs interface is
> unnecessary overhead.
>
> With this approach, when needed, we use:
>
> if _has_fs_sysfs_attr $dev <sysfs-interface>; then
> verify_sysfs_syntax <sysfs-interface> <value>
> fi
One test instance per sysfs attribute, please.
i.e. move verify_sysfs_syntax() gets moved to common/ somewhere,
then the test for any given sysfs attr is a simple 10 liner with a
fixed golden output.
We can then do the same sort of input testing for sysfs attrs that
belong to other filesystems, too, not just a handful of btrfs
specific ones this test touches. I'd much prefer such tests are
largely generic like so:
....
_require_fs_sysfs_attr $TEST_DEV <sysfs-attr>
_verify_sysfs_syntax $TEST_DEV <sysfs-attr>
exit
If the sysfs-attr doesn't exist, then the test is _not_run and
this emits a log file note that can be captured. If it does exist
and doesn't behave correctly, the test then fails.
Note that things like "test not run because sysfs attr does not
exist" notes in the log files can be important for QE
people trying to track whether backports for older/stable kernels
work correctly. The proposed test is completely silent on whether
any specific sysfs attr was tested or not, and that's not really
helpful in identifying whether something works correctly or not...
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2025-02-04 0:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 15:19 [PATCH 0/3] fstests: btrfs: add test case to validate sysfs input arguments Anand Jain
2025-01-29 15:19 ` [PATCH 1/3] fstests: common/rc: set_fs_sysfs_attr: redirect errors to stdout Anand Jain
2025-01-29 15:19 ` [PATCH 2/3] fstests: filter: helpers for sysfs error filtering Anand Jain
2025-01-29 15:19 ` [PATCH 3/3] fstests: btrfs: testcase for sysfs policy syntax verification Anand Jain
2025-01-30 20:50 ` Dave Chinner
2025-01-31 6:43 ` Anand Jain
2025-02-04 0:18 ` Dave Chinner [this message]
2025-02-05 11:06 ` Anand Jain
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=Z6FcxffA-v4-01lI@dread.disaster.area \
--to=david@fromorbit.com \
--cc=anand.jain@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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