From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 2/2] controllers/memcg_test_3: Add new regression test
Date: Mon, 5 Jun 2017 17:20:09 +0800 [thread overview]
Message-ID: <59352249.3080904@cn.fujitsu.com> (raw)
In-Reply-To: <20170530130217.GA25921@rei.lan>
Hi!
Thanks for your review, and sorry for the late reply.
On 05/30/2017 09:02 PM, Cyril Hrubis wrote:
> Hi!
>> +/*
>> + * This is a regression test for a crash caused by memcg function
>> + * reentrant on RHEL6. When doing rmdir(), a pending signal can
>> + * interrupt the execution and lead to cgroup_clear_css_refs()
>> + * being entered repeatedly, this results in a BUG_ON().
>> + *
>> + * This bug was introduced by following RHEL6 patch on 2.6.32-488.el6:
>> + *
>> + * [mm] memcg: fix race condition between memcg teardown and swapin
>> + * Bugzilla: 1001197
>
> Can you rather add a link here instead? Just "Bugzilla:" is too vague.
>
OK, I will add a Bugzilla link instead, and add the patch url of ftp as well.
>> + * This test can crash the buggy kernel on RHEL6.6GA, and the bug
>> + * was fixed by following patch on 2.6.32-536.el6:
>> + *
>> + * [mm] memcg: fix crash in re-entrant cgroup_clear_css_refs()
>> + * Bugzilla: 1168185
>> + */
>> +
>> +#include <errno.h>
>> +#include <unistd.h>
>> +#include <stdlib.h>
>> +#include <sys/types.h>
>> +#include <sys/wait.h>
>> +#include "tst_test.h"
>> +
>> +#define MNTPOINT "memcg"
>> +#define SUBDIR "memcg/testdir"
>> +
>> +static int mount_flag;
>> +
>> +static struct tst_kern_exv kvers[] = {
>> + {"RHEL6", "2.6.32-488"},
>> + {NULL, NULL}
>> +};
>> +
>> +static void sighandler(int sig LTP_ATTRIBUTE_UNUSED)
>> +{
>> +
>> +}
>> +
>> +static void do_child(void)
>> +{
>> + while (1)
>> + SAFE_KILL(getppid(), SIGUSR1);
>> +
>> + exit(0);
>> +}
>> +
>> +static void do_test(void)
>> +{
>> + int i;
>> + pid_t cpid = -1;
>> +
>> + SAFE_SIGNAL(SIGUSR1, sighandler);
>> +
>> + cpid = SAFE_FORK();
>> + if (cpid == 0)
>> + do_child();
>
> Shouldn't we wait here untill the child is actually running?
>
> I think that with just 10 iteration in the code below we may as well
> finish the loop too fast.
>
> So what about incrementing a counter in the signal handler and loop
> until it reaches some small value (50 or something)?
>
Yes, we need to ensure the synchronization.
It is a good idea to use a counter in signal handler, but 50 or hundreds
is too small, since I tested and found that the signal is triggered way
much faster than the loop in parent.
I have tested that the value can be set to 50000, which makes sure 100%
reproducible in buggy kernel and that the test can be done within 1 second
when there is no bug.
>> + for (i = 0; i < 10; i++) {
>> + if (access(SUBDIR, F_OK))
>> + SAFE_MKDIR(SUBDIR, 0644);
>> + rmdir(SUBDIR);
>> + }
>> +
>> + SAFE_KILL(cpid, SIGKILL);
>> + SAFE_WAIT(NULL);
>> +
>> + tst_res(TPASS, "Bug not reproduced");
>> +}
>> +
>> +static void setup(void)
>> +{
>> + struct utsname buf;
>> +
>> + SAFE_UNAME(&buf);
>> + if (!strstr(buf.release, ".el6"))
>> + tst_brk(TCONF, "This test can only run on RHEL6");
>> +
>> + if (tst_kvercmp2(2, 6, 24, kvers) < 0)
>> + tst_brk(TCONF, "This test requires kernel >= 2.6.32-488.el6");
>
> Why do we skip this test on anything but RHEL6? It does not seem to me
> that the test actually does something that couldn't be tested on any
> other Linux distribution. We only have to check for memcg support here
> instead.
>
OK, I got it.
Best Regards,
Guangwen Feng
>> + SAFE_MKDIR(MNTPOINT, 0644);
>> +
>> + SAFE_MOUNT("memcg", MNTPOINT, "cgroup", 0, "memory");
>> + mount_flag = 1;
>> +}
>> +
>> +static void cleanup(void)
>> +{
>> + if (!access(SUBDIR, F_OK))
>> + SAFE_RMDIR(SUBDIR);
>> +
>> + if (mount_flag)
>> + tst_umount(MNTPOINT);
>> +}
>> +
>> +static struct tst_test test = {
>> + .tid = "memcg_test_3",
>> + .needs_root = 1,
>> + .needs_tmpdir = 1,
>> + .forks_child = 1,
>> + .setup = setup,
>> + .cleanup = cleanup,
>> + .test_all = do_test,
>> +};
>> --
>> 1.8.4.2
>>
>>
>>
>>
>> --
>> Mailing list info: https://lists.linux.it/listinfo/ltp
>
next prev parent reply other threads:[~2017-06-05 9:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 10:05 [LTP] [PATCH 1/2] SAFE_MACROS: Add SAFE_UNAME() Guangwen Feng
2017-05-09 10:05 ` [LTP] [PATCH 2/2] controllers/memcg_test_3: Add new regression test Guangwen Feng
2017-05-09 11:15 ` Guangwen Feng
2017-05-09 11:21 ` [LTP] [PATCH v2 " Guangwen Feng
2017-05-30 13:02 ` Cyril Hrubis
2017-06-05 9:20 ` Guangwen Feng [this message]
2017-06-05 9:23 ` [LTP] [PATCH v3] " Guangwen Feng
2017-06-14 6:10 ` Guangwen Feng
2017-06-14 6:12 ` [LTP] [PATCH v4] " Guangwen Feng
2017-06-21 10:44 ` Guangwen Feng
2017-06-22 9:27 ` Cyril Hrubis
2017-06-22 9:43 ` Guangwen Feng
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=59352249.3080904@cn.fujitsu.com \
--to=fenggw-fnst@cn.fujitsu.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 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.