From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [RFC] [PATCH] lib: Add support for test tags
Date: Thu, 8 Nov 2018 12:30:07 -0500 (EST) [thread overview]
Message-ID: <156962223.71358453.1541698207250.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20181107142209.8965-1-chrubis@suse.cz>
Hi,
----- Original Message -----
> This is just proof of concept of moving some of the test metadata into
> more structured form. If implemented it will move some information from
> comments in the test source code to an array to the tst_test structure.
>
> It's not finished and certainly not set into a stone, this patch is
> mainly intended to start a discussion.
>
> The newly introduced test tags are generic name-value pairs that can
> hold test metadata, the intended use for now is to store kernel commit
> hashes for kernel reproducers as well as CVE ids. The mechanism is
> however choosen to be very generic so that it's easy to add basically
> any information later on.
>
> As it is the main purpose is to print hints for a test failures. If a
> test that has been written as a kernel reproducer fails it prints nice
> URL pointing to a kernel commit that may be missing.
>
> Example output:
>
> tst_test.c:1145: INFO: Timeout per run is 0h 05m 00s
> add_key02.c:98: FAIL: unexpected error with key type 'asymmetric': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'cifs.idmap': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'cifs.spnego': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'pkcs7_test': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'rxrpc': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'rxrpc_s': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'user': EINVAL
> add_key02.c:98: FAIL: unexpected error with key type 'logon': EINVAL
>
> HINT: This is a regression test for linux kernel, see commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5649645d725c
>
> HINT: This test also tests for CVE-2017-15274, see:
>
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15274
>
> Summary:
> passed 0
> failed 8
> skipped 0
> warnings 0
>
> This commit also adds adds the -q test flag, that can be used to query
> test information, which includes these tags, but is not limited to them.
>
> The main inteded use for the query operation is to export test metadata
> and constraints to the test execution system. The long term goal for
> this would be parallel test execution as for this case the test runner
> would need to know which global system resources is the test using to
> avoid unexpected failures.
>
> So far it exposes only if test needs root and if block device is needed
> for the test, but I would expect that we will need a few more tags for
> various resources, one that comes to my mind would be "test is using
> SystemV SHM" for that we can do something as add a "constraint" tag with
> value "SysV SHM" or anything else that would be fitting. Another would
> be "Test is changing system wide clocks", etc.
>
> So far the output from the query operation looks as:
>
> sh$ ./add_key02 -q
> {
> "root": false
> "blk_device": false
> "linux-git": "5649645d725c"
> "CVE": "2017-15274"
> }
So, only way to get metadata for tools is to run the test
with -q on supported target? (since I assume when
TST_TEST_TCONF branch hits, there won't be any data).
Would there be any benefit to having metadata in a (json)
file from the start? Negative would be likely duplicating
things like "needs_root". Positive is we could check for
errors/typos during build time.
Regards,
Jan
>
> The format is meant to be machine-parseable, but it is certainly not
> final as there are no consumers for the data yet.
>
> Another nice feature of having this information in the test runner is
> that we can include the URL pointing to a kernel git commit fixing the
> issue even for kernel reproducers that crashed the kernel under test and
> failed to write out any logs. Which is not that important I guess, but
> still nice to have.
next prev parent reply other threads:[~2018-11-08 17:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-07 14:22 [LTP] [RFC] [PATCH] lib: Add support for test tags Cyril Hrubis
2018-11-08 5:11 ` Li Wang
2018-11-08 12:52 ` Cyril Hrubis
2018-11-08 20:01 ` [LTP] [Automated-testing] " Tim.Bird
2018-11-09 12:28 ` Cyril Hrubis
2018-11-12 16:09 ` Tim.Bird
2018-11-16 14:51 ` Cyril Hrubis
2018-11-08 17:30 ` Jan Stancek [this message]
2018-11-08 20:19 ` Tim.Bird
2018-11-09 10:28 ` Cyril Hrubis
2018-11-12 16:25 ` Tim.Bird
2018-11-16 15:02 ` Cyril Hrubis
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=156962223.71358453.1541698207250.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=ltp@lists.linux.it \
/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