public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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.


  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