From: Wei Gao via ltp <ltp@lists.linux.it>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: Li Wang <liwan@redhat.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v5] kill01: New case cgroup kill
Date: Wed, 15 Mar 2023 08:55:32 -0400 [thread overview]
Message-ID: <20230315125532.GB10248@localhost> (raw)
In-Reply-To: <87ttyo6g7o.fsf@suse.de>
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.
> > +{
> > + 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.
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?
> > + 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!
>
> > + .needs_cgroup_ver = TST_CG_V2,
> > +};
> > --
> > 2.35.3
>
> --
> Thank you,
> Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-03-15 12:55 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 [this message]
2023-03-16 11:10 ` Richard Palethorpe
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=20230315125532.GB10248@localhost \
--to=ltp@lists.linux.it \
--cc=liwan@redhat.com \
--cc=rpalethorpe@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.