public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 3/4] syscalls/keyctl07: new test for oops when reading negative key
Date: Tue, 17 Oct 2017 11:19:56 +0200	[thread overview]
Message-ID: <20171017091956.GA21124@rei> (raw)
In-Reply-To: <20171016194748.GE121701@gmail.com>

Hi!
> Hi Cyril, I'll send out a new version that does that.  But please check that I'm
> handling the exit status from the child process correctly because I wasn't 100%
> sure how to do it.  (And I'm surprised more tests haven't run into this problem.
> Maybe there should be something in the library for this, like being able to set
> '.fail_on_sigkill = 1' in the 'struct tst_test'?  Or at least a different
> version of tst_reap_children().)

Agree that the current state of the API for waiting child is indeed
suboptimal. The problem is that some tests should succeed on SIGKILL,
some fail, etc. So the interface would have to be quite flexible. Rather
than that I've decided to add new tst_strstatus() function so that we
can easily print what happened to the child. With that you can pick the
specific cases that should be mapped to TPASS and TFAIL first, then
handle the rest with TBROK.

Generally it's supposed to be used as:

	SAFE_WAIT(&status);

	if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
		tst_res(TPASS, ...);
		return;
	}

	if (WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL) {
		tst_res(TFAIL, ...);
		return;
	}

	tst_brk(TBROK, "Child ", tst_strstatus(status);


I guess that additional macros that would simplify the if conditions
would be helpful as well, something as TST_EXITEDWITH(status, 0) and
TST_SIGNALEDBY(status, SIGKILL).


We may as well try some kind of data driven approach with an array of
structures describing the exit-status to result mapping, howerever I
think that it would be an overkill in this case.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-10-17  9:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 20:42 [LTP] [PATCH v2 0/4] ltp: add tests for some recently-fixed keyrings bugs Eric Biggers
2017-10-12 20:42 ` [LTP] [PATCH v2 1/4] lapi/keyctl.h: add a few missing definitions Eric Biggers
2017-10-12 20:42 ` [LTP] [PATCH v2 2/4] syscalls/keyctl06: new test for keyring_read() buffer overrun Eric Biggers
2017-10-12 20:42 ` [LTP] [PATCH v2 3/4] syscalls/keyctl07: new test for oops when reading negative key Eric Biggers
2017-10-16 10:22   ` Cyril Hrubis
2017-10-16 19:47     ` Eric Biggers
2017-10-17  9:19       ` Cyril Hrubis [this message]
2017-10-12 20:42 ` [LTP] [PATCH v2 4/4] syscalls/add_key03: new test for forging user keyrings Eric Biggers
2017-10-13  7:25 ` [LTP] [PATCH v2 0/4] ltp: add tests for some recently-fixed keyrings bugs Petr Vorel

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=20171017091956.GA21124@rei \
    --to=chrubis@suse.cz \
    --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