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 1/2] syscalls/add_key05: add new test for the length of payload
Date: Tue, 21 Jan 2020 16:13:43 +0100	[thread overview]
Message-ID: <20200121151342.GD6337@rei> (raw)
In-Reply-To: <1579420198-29651-1-git-send-email-xuyang2018.jy@cn.fujitsu.com>

Hi!
> Seeing add_key manpages, the lenth of payload for "user"/"logon"
> is 32767, this value is up tp 1M for "big_key". For "keyring" type
> , this value is zero.
> 
> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> ---
>  runtest/syscalls                              |  1 +
>  testcases/kernel/syscalls/add_key/.gitignore  |  1 +
>  testcases/kernel/syscalls/add_key/add_key05.c | 99 +++++++++++++++++++
>  3 files changed, 101 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/add_key/add_key05.c
> 
> diff --git a/runtest/syscalls b/runtest/syscalls
> index f58fefe17..830dfc8b7 100644
> --- a/runtest/syscalls
> +++ b/runtest/syscalls
> @@ -18,6 +18,7 @@ add_key01 add_key01
>  add_key02 add_key02
>  add_key03 add_key03
>  add_key04 add_key04
> +add_key05 add_key05
>  
>  adjtimex01 adjtimex01
>  adjtimex02 adjtimex02
> diff --git a/testcases/kernel/syscalls/add_key/.gitignore b/testcases/kernel/syscalls/add_key/.gitignore
> index b9a04214d..f57dc2228 100644
> --- a/testcases/kernel/syscalls/add_key/.gitignore
> +++ b/testcases/kernel/syscalls/add_key/.gitignore
> @@ -2,3 +2,4 @@
>  /add_key02
>  /add_key03
>  /add_key04
> +/add_key05
> diff --git a/testcases/kernel/syscalls/add_key/add_key05.c b/testcases/kernel/syscalls/add_key/add_key05.c
> new file mode 100644
> index 000000000..a6d4c1a02
> --- /dev/null
> +++ b/testcases/kernel/syscalls/add_key/add_key05.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2020 FUJITSU LIMITED. All rights reserved.
> + * Author: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
> + *
> + * This case test various key type can support how many long
> + * bytes payload.
> + * keyring: 0 bytes
> + * user/logon: 32767 bytes
> + * big_key: 1M -1byte
> + */
> +
> +#include <errno.h>
> +#include "tst_test.h"
> +#include "lapi/keyctl.h"
> +
> +struct tcase {
> +	const char *type;
> +	const char *desc;
> +	size_t plen;
> +	int pass_flag;
> +	char *message;
> +} tcases[] = {
> +	{"keyring", "abc", 0, 1,
> +	"The key type is keyrings and plen is 0"},
> +
> +	{"keyring", "bcd", 1, 0,
> +	"the key type is keyrings and plen is 1"},
> +
> +	{"user", "cde", 32767, 1,
> +	"The key type is user and plen is 32767"},
> +
> +	{"user", "def", 32768, 0,
> +	"The key type is user and plen is 32768"},
> +
> +	{"logon", "ef:g", 32767, 1,
> +	"The key type is logon and plen is 32767"},
> +
> +	{"logon", "fg:h", 32768, 0,
> +	"The key type is logon and plen is 32768"},
> +
> +	{"big_key", "ghi", (1 << 20) - 1, 1,
> +	"The key type is big_key and plen is 1048575"},
> +
> +	{"big_key", "hij", 1 << 20, 0,
> +	"The key type is big_key and plen is 1048576"},
> +};
> +
> +static char *buf;
> +static unsigned int logon_nsup, big_key_nsup;
> +
> +static void verify_add_key(unsigned int n)
> +{
> +	struct tcase *tc = &tcases[n];
> +
> +	tst_res(TINFO, "%s", tc->message);
> +
> +	if (!strcmp(tc->type, "logon") && logon_nsup) {
> +		tst_res(TINFO,
> +			"current system doesn't support logon key type, skip it");
                     This should be TCONF and the message could be much
		     shorther and to the point, something as:

		     tst_res(TCONF, "skipping unsupported logon key");
> +		return;
> +	}
> +
> +	if (!strcmp(tc->type, "big_key") && big_key_nsup) {
> +		tst_res(TINFO,
> +			"current system doesn't support big_key key type, skip it");

Here as well.

> +		return;
> +	}
> +
> +	TEST(add_key(tc->type, tc->desc, buf, tc->plen, KEY_SPEC_THREAD_KEYRING));
> +	if (TST_RET == -1) {
> +		if (TST_ERR == EINVAL)
> +			tst_res(tc->pass_flag ? TFAIL : TPASS, "add_key call failed as expected");
> +		else
> +			tst_res(TFAIL | TTERRNO, "add_key call failed expected EINVAL but got");

This is a bit confusing, we may get the messages even in a case that the
key is supposed to be successfully created, right?

I guess that message "TFAIL: add_key call failed as expected" is not
right.

Can we separate the negative a positive messages so that they are less
confusing?

> +		return;
> +	}
> +	tst_res(tc->pass_flag ? TPASS : TFAIL, "add_key call succeeded");
> +}
> +
> +static void setup(void)
> +{
> +	TEST(add_key("logon", "test:sup_logon", buf, 64, KEY_SPEC_THREAD_KEYRING));
> +	if (TST_RET == -1)
> +		logon_nsup = 1;
> +
> +	TEST(add_key("big_key", "sup_big_key", buf, 64, KEY_SPEC_THREAD_KEYRING));
> +	if (TST_RET == -1)
> +		big_key_nsup = 1;
> +}
> +
> +static struct tst_test test = {
> +	.setup = setup,
> +	.tcnt = ARRAY_SIZE(tcases),
> +	.test = verify_add_key,
> +	.bufs = (struct tst_buffers []) {
> +		{&buf, .size = 1 << 20},

We actually need different buffer for each different plen size, because
the sole purpose of the buffer is to map a unaccessible page right after
the end of the buffer to catch off-by-one accesses.

> +		{}
> +	}
> +};
> -- 
> 2.18.0
> 
> 
> 
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

-- 
Cyril Hrubis
chrubis@suse.cz

  parent reply	other threads:[~2020-01-21 15:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-19  7:49 [LTP] [PATCH 1/2] syscalls/add_key05: add new test for the length of payload Yang Xu
2020-01-19  7:49 ` [LTP] [PATCH 2/2] syscalls/add_key01: remove duplicated case Yang Xu
2020-01-21 14:50   ` Cyril Hrubis
2020-01-21 15:13 ` Cyril Hrubis [this message]
2020-01-22  1:51   ` [LTP] [PATCH 1/2] syscalls/add_key05: add new test for the length of payload Yang Xu
2020-01-22  5:26   ` [LTP] [PATCH v2] syscalls/add_key01: test " Yang Xu
2020-01-23 11:13     ` Cyril Hrubis
2020-01-23 12:44       ` Yang Xu
2020-01-23 12:56         ` Cyril Hrubis
2020-01-23 13:06     ` 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=20200121151342.GD6337@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