public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Wei Gao <wegao@suse.com>
Cc: Li Wang <liwan@redhat.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v5] kill01: New case cgroup kill
Date: Thu, 16 Mar 2023 11:10:07 +0000	[thread overview]
Message-ID: <87jzzg3oqg.fsf@suse.de> (raw)
In-Reply-To: <20230315125532.GB10248@localhost>


Wei Gao <wegao@suse.com> writes:

> On Mon, Mar 13, 2023 at 10:45:12AM +0000, Richard Palethorpe wrote:
>> Hello,
>> 
>> > +static int wait_for_pid(pid_t pid)
>> > +{
>> > +	int status, ret;
>> > +
>> > +again:
>> > +	ret = waitpid(pid, &status, 0);
>> > +	if (ret == -1) {
>> > +		if (errno == EINTR)
>> > +			goto again;
>> > +
>> > +		return -1;
>> > +	}
>> > +
>> > +	if (!WIFEXITED(status))
>> > +		return -1;
>> > +
>> > +	return WEXITSTATUS(status);
>> > +}
>> 
>> We have tst_reap_children for this, but this just appears to be wrong
>> for this test.
> tst_reap_children can not return reason of status, such as i need call 
> WIFSIGNALED(wstatus) in next patch to make sure children is killed by 
> signal.
>
>> > + * A simple process running in a sleep loop until being
>> > + * re-parented.
>> > + */
>> > +static void child_fn(void)
>> > +{
>> > +	int ppid = getppid();
>> > +
>> > +	while (getppid() == ppid)
>> > +		usleep(1000);
>> > +
>> > +}
>> > +
>> > +static int cg_run_nowait(const struct tst_cg_group *const cg,
>> > +		  void (*fn)(void))
>> 
>> Why keep this function?
>> 
>> If you want to convert tests to LTP, then don't do the minimum possible
>> to use the LTP API. Use as much of it as possible otherwise we are just
>> importing brittle self tests.
>> 
> function is useful and wrap the fork action & put pid into cgroup.procs,
> is there any LTP API can replace this function? Could you help give
> example.

IMO you don't need to wrap fork or SAFE_CG_PRINTF, just write it inline.

>> > +{
>> > +	int pid;
>> > +
>> > +	pid = SAFE_FORK();
>> > +	if (pid == 0) {
>> > +		SAFE_CG_PRINTF(cg, "cgroup.procs", "%d", getpid());
>> > +		fn();
>> > +	}
>> > +
>> > +	return pid;
>> > +}
>> > +
>> > +static int cg_wait_for_proc_count(const struct tst_cg_group *cg, int count)
>> > +{
>> > +	int attempts;
>> > +	char *ptr;
>> > +
>> > +	for (attempts = 100; attempts >= 0; attempts--) {
>> > +		int nr = 0;
>> > +
>> > +		SAFE_CG_READ(cg, "cgroup.procs", buf, buf_len);
>> > +
>> > +		for (ptr = buf; *ptr; ptr++)
>> > +			if (*ptr == '\n')
>> > +				nr++;
>> > +
>> > +		if (nr >= count)
>> > +			return 0;
>> > +
>> > +		usleep(100000);
>> 
>> It's best to avoid arbitrary sleep values and attempts. You could use
>> TST_CHECKPOINT* or increment a counter in some shared memory with
>> SAFE_MMAP and tst_atomic_inc.
>> 
> I will try to use TST_CHECKPOINT* to sync before call this function
>> > +	}
>> > +
>> > +	return -1;
>> > +}
>> > +
>> > +static void run(void)
>> > +{
>> > +	pid_t pids[MAX_PID_NUM];
>> > +	int i;
>> > +
>> > +	cg_child_test_simple = tst_cg_group_mk(tst_cg,
>> > "cg_test_simple");
>> > +
>> > +	memset(buf, 0, buf_len);
>> 
>> IIRC guarded buffers are zeroed already.
> Already explained by Li Wang in other email.
>> 
>> > +
>> > +	for (i = 0; i < pid_num; i++)
>> > +		pids[i] = cg_run_nowait(cg_child_test_simple, child_fn);
>> 
>> If the parent is killed and the children are moved then they will return
>> and cause a fork bomb.
> There is no extra fork action in child_fn so all child_fn will
> reparent and exit.

I don't see how it will exit? It seems like it will just return.

Possibly I just missed it, but that's why I have an issue with the
function pointer as well.

> So i do not think fork bomb will happen.
>> 
>> This is not obvious because of the unecessary indirection (function
>> pointer and functions).
>> 
>> > +
>> > +	TST_EXP_PASS(cg_wait_for_proc_count(cg_child_test_simple,
>> > pid_num));
>> 
>> If this fails then there will be little information to debug it. This is
>> a common issue with the self tests which we will be importing into the LTP.
>> 
> Add extra log info into this function maybe help, what's your
> suggestion?

Yes, something like that.

>> > +	SAFE_CG_PRINTF(cg_child_test_simple, "cgroup.kill", "%d", 1);
>> > +
>> > +	for (i = 0; i < pid_num; i++) {
>> > +		/* wait_for_pid(pids[i]); */
>> > +		TST_EXP_PASS_SILENT(wait_for_pid(pids[i]) == SIGKILL);
>> 
>> It seems wait_for_pid will never == SIGKILL. The function does not
>> inspect the signal a process was killed with at all.
>> 
>> The test passes becaues this is not the correct use of TST_EXP_PASS*.
> Good catch! Thanks a lot for finding this, i should use WIFSIGNALED 
> to translate status and check children killed by SIGKILL, will fix this
> in next patch.
>> 
>> > +	}
>> > +
>> > +	cg_child_test_simple = tst_cg_group_rm(cg_child_test_simple);
>> > +}
>> > +
>> > +static void setup(void)
>> > +{
>> > +	buf = tst_alloc(buf_len);
>> 
>> Simple allocations like this can be done in the test struct.
> This already discussed with Wang Li, compile error will happen since buf_len 
> not fixed in my case.
>> 
>> > +}
>> > +
>> > +static struct tst_test test = {
>> > +	.test_all = run,
>> > +	.setup = setup,
>> > +	.forks_child = 1,
>> > +	.max_runtime = 15,
>> > +	.needs_cgroup_ctrls = (const char *const []){ "memory", NULL },
>> 
>> Why do we need the memory controller?
>> 
>> If it is just to make the LTP library happy, then you can change the
>> library instead (e.g. add a "cgroup" pseudo controller if we didn't do
>> that already).
> You guess right, i just go quick way to let LTP happy xD
> I will check library and try to implement this.
>
> Thanks again for your valuable feedback!

Thanks!

>> 
>> > +	.needs_cgroup_ver = TST_CG_V2,
>> > +};
>> > -- 
>> > 2.35.3
>> 
>> -- 
>> Thank you,
>> Richard.


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2023-03-16 11:44 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24  2:38 [LTP] [PATCH v1] kill01: New case cgroup kill Wei Gao via ltp
2023-02-24 10:12 ` Cyril Hrubis
2023-02-24 12:27   ` Wei Gao via ltp
2023-03-05  9:10 ` [LTP] [PATCH v2] " Wei Gao via ltp
2023-03-06 10:16   ` Li Wang
2023-03-06 14:54     ` Wei Gao via ltp
2023-03-06 15:13   ` [LTP] [PATCH v3] " Wei Gao via ltp
2023-03-06 23:57     ` [LTP] [PATCH v4] " Wei Gao via ltp
2023-03-07  7:13       ` Li Wang
2023-03-07  8:27         ` Wei Gao via ltp
2023-03-07 11:23           ` Li Wang
2023-03-07  8:51       ` [LTP] [PATCH v5] " Wei Gao via ltp
2023-03-07 11:37         ` Li Wang
2023-03-09 21:40         ` Petr Vorel
2023-03-15 12:23           ` Wei Gao via ltp
2023-03-13 10:45         ` Richard Palethorpe
2023-03-15  5:47           ` Li Wang
2023-03-15 12:55           ` Wei Gao via ltp
2023-03-16 11:10             ` Richard Palethorpe [this message]
2023-03-18  5:00               ` Wei Gao via ltp
2023-03-15 18:52           ` Petr Vorel
2023-03-18  4:52         ` [LTP] [PATCH v6] " Wei Gao via ltp
2023-03-29  6:28           ` Petr Vorel
2023-04-19 15:18           ` [LTP] [PATCH v7 0/2] " Wei Gao via ltp
2023-04-19 15:18             ` [LTP] [PATCH v7 1/2] " Wei Gao via ltp
2023-04-19 15:18             ` [LTP] [PATCH v7 2/2] tst_cgroup.c: Add a cgroup pseudo controller Wei Gao via ltp
2023-04-21  1:26             ` [LTP] [PATCH v8 0/2] kill01: New case cgroup kill Wei Gao via ltp
2023-04-21  1:26               ` [LTP] [PATCH v8 1/2] " Wei Gao via ltp
2023-04-21  6:35                 ` Li Wang
2023-04-21  1:26               ` [LTP] [PATCH v8 2/2] tst_cgroup.c: Add a cgroup pseudo controller Wei Gao via ltp
2023-04-21  4:33                 ` Li Wang
2023-04-21 10:58                 ` Cyril Hrubis
2023-04-22 13:53               ` [LTP] [PATCH v9 0/2] kill01: New case cgroup kill Wei Gao via ltp
2023-04-22 13:53                 ` [LTP] [PATCH v9 1/2] " Wei Gao via ltp
2023-04-26 13:11                   ` Cyril Hrubis
2023-04-27 12:13                     ` Shivani Samala
2023-04-27 12:18                       ` Cyril Hrubis
2023-04-22 13:53                 ` [LTP] [PATCH v9 2/2] tst_cgroup.c: Add a cgroup pseudo controller Wei Gao via ltp
2023-04-23  6:46                   ` Li Wang
2023-04-26 13:12                   ` Cyril Hrubis
2023-04-28  0:16                 ` [LTP] [PATCH v10 0/2] kill01: New case cgroup kill Wei Gao via ltp
2023-04-28  0:17                   ` [LTP] [PATCH v10 1/2] " Wei Gao via ltp
2023-04-28  8:04                     ` Petr Vorel
2023-04-28  0:17                   ` [LTP] [PATCH v10 2/2] tst_cgroup.c: Add a cgroup base controller Wei Gao via ltp
2023-04-28  7:59                     ` Petr Vorel
2023-04-28 10:10                   ` [LTP] [PATCH v11 0/2] New case test cgroup kill feature Wei Gao via ltp
2023-04-28 10:10                     ` [LTP] [PATCH v11 1/2] tst_cgroup.c: Add a cgroup base controller Wei Gao via ltp
2023-04-28 10:10                     ` [LTP] [PATCH v11 2/2] cgroup_core03.c: New case test cgroup kill feature Wei Gao via ltp
2023-04-30  7:48                     ` [LTP] [PATCH v12 0/2] " Wei Gao via ltp
2023-04-30  7:48                       ` [LTP] [PATCH v12 1/2] tst_cgroup.c: Add a cgroup base controller Wei Gao via ltp
2023-04-30 13:44                         ` Li Wang
2023-04-30 23:39                           ` Wei Gao via ltp
2023-05-02  6:56                           ` Petr Vorel
2023-05-02  9:12                           ` Petr Vorel
2023-04-30  7:48                       ` [LTP] [PATCH v12 2/2] cgroup_core03.c: New case test cgroup kill feature Wei Gao via ltp
2023-04-30 13:44                         ` Li Wang

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=87jzzg3oqg.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=liwan@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=wegao@suse.com \
    /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