* [LTP] [PATCH 1/2] lib: add SAFE_RENAME() @ 2014-07-15 10:13 Xiaoguang Wang 2014-07-15 10:13 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang 0 siblings, 1 reply; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-15 10:13 UTC (permalink / raw) To: ltp-list Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> --- include/safe_macros.h | 5 +++++ lib/safe_macros.c | 16 ++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/include/safe_macros.h b/include/safe_macros.h index f521347..a79c4ad 100644 --- a/include/safe_macros.h +++ b/include/safe_macros.h @@ -266,5 +266,10 @@ int safe_mkfifo(const char *file, const int lineno, #define SAFE_MKFIFO(cleanup_fn, pathname, mode) \ safe_mkfifo(__FILE__, __LINE__, (cleanup_fn), (pathname), (mode)) +int safe_rename(const char *file, const int lineno, void (*cleanup_fn)(void), + const char *oldpath, const char *newpath); +#define SAFE_RENAME(cleanup_fn, oldpath, newpath) \ + safe_rename(__FILE__, __LINE__, (cleanup_fn), (oldpath), (newpath)) + #endif /* __SAFE_MACROS_H__ */ #endif /* __TEST_H__ */ diff --git a/lib/safe_macros.c b/lib/safe_macros.c index a07cffa..eefacae 100644 --- a/lib/safe_macros.c +++ b/lib/safe_macros.c @@ -768,3 +768,19 @@ int safe_mkfifo(const char *file, const int lineno, return rval; } + +int safe_rename(const char *file, const int lineno, void (*cleanup_fn)(void), + const char *oldpath, const char *newpath) +{ + int rval; + + rval = rename(oldpath, newpath); + + if (rval == -1) { + tst_brkm(TBROK | TERRNO, cleanup_fn, + "%s:%d: rename(%s, %s) failed", + file, lineno, oldpath, newpath); + } + + return rval; +} -- 1.8.2.1 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-15 10:13 [LTP] [PATCH 1/2] lib: add SAFE_RENAME() Xiaoguang Wang @ 2014-07-15 10:13 ` Xiaoguang Wang 2014-07-15 10:21 ` Xiaoguang Wang 2014-07-21 9:04 ` Jan Stancek 0 siblings, 2 replies; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-15 10:13 UTC (permalink / raw) To: ltp-list Note: this test has already been in xfstests generic/028 test case, I just port it to LTP. Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race condition that causes getcwd(2) to return "/" instead of correct path. 232d2d6 dcache: Translating dentry into pathname without taking rename_lock And these two kernel commits have fixed this bug: ede4cebce16f5643c61aedd6d88d9070a1d23a68 prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts f6500801522c61782d4990fa1ad96154cb397cd4 f650080 __dentry_path() fixes This test is to check whether this bug exists in the running kernel, or whether this bug has been fixed. Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> --- runtest/ltplite | 1 + runtest/stress.part3 | 1 + runtest/syscalls | 1 + testcases/kernel/syscalls/.gitignore | 1 + testcases/kernel/syscalls/getcwd/getcwd04.c | 143 ++++++++++++++++++++++++++++ 5 files changed, 147 insertions(+) create mode 100644 testcases/kernel/syscalls/getcwd/getcwd04.c diff --git a/runtest/ltplite b/runtest/ltplite index 50653a9..1457908 100644 --- a/runtest/ltplite +++ b/runtest/ltplite @@ -275,6 +275,7 @@ getcontext01 getcontext01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/runtest/stress.part3 b/runtest/stress.part3 index 39ce807..368c640 100644 --- a/runtest/stress.part3 +++ b/runtest/stress.part3 @@ -214,6 +214,7 @@ getcontext01 getcontext01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/runtest/syscalls b/runtest/syscalls index fbed9cb..13218e3 100644 --- a/runtest/syscalls +++ b/runtest/syscalls @@ -329,6 +329,7 @@ getcpu01 getcpu01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/testcases/kernel/syscalls/.gitignore b/testcases/kernel/syscalls/.gitignore index b9d49cf..fd3282b 100644 --- a/testcases/kernel/syscalls/.gitignore +++ b/testcases/kernel/syscalls/.gitignore @@ -273,6 +273,7 @@ /getcwd/getcwd01 /getcwd/getcwd02 /getcwd/getcwd03 +/getcwd/getcwd04 /getdents/getdents01 /getdents/getdents01_64 /getdents/getdents02 diff --git a/testcases/kernel/syscalls/getcwd/getcwd04.c b/testcases/kernel/syscalls/getcwd/getcwd04.c new file mode 100644 index 0000000..a0285cb --- /dev/null +++ b/testcases/kernel/syscalls/getcwd/getcwd04.c @@ -0,0 +1,143 @@ +/* + * Copyright (c) 2014 Fujitsu Ltd. + * Author: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See + * the GNU General Public License for more details. + */ + +/* + * Note: this test has already been in xfstests generic/028 test case, + * I just port it to LTP. + * + * Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race + * condition that causes getcwd(2) to return "/" instead of correct path. + * 232d2d6 dcache: Translating dentry into pathname without + * taking rename_lock + * + * And these two kernel commits fixed the bug: + * ede4cebce16f5643c61aedd6d88d9070a1d23a68 + * prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts + * f6500801522c61782d4990fa1ad96154cb397cd4 + * f650080 __dentry_path() fixes + * + * This test is to check whether this bug exists in the running kernel, + * or whether this bug has been fixed. + * + */ + +#include <stdio.h> +#include <errno.h> +#include <fcntl.h> +#include <sys/types.h> +#include <unistd.h> + +#include "usctest.h" +#include "test.h" +#include "safe_macros.h" + +#define TIMEOUT 5 + +static void setup(void); +static void cleanup(void); +static void do_child(void); +static void sigproc(int sig); +static volatile sig_atomic_t end; +static char init_cwd[PATH_MAX]; + +char *TCID = "getcwd04"; +int TST_TOTAL = 1; + +int main(int ac, char **av) +{ + int status; + const char *msg; + char cur_cwd[PATH_MAX]; + pid_t child; + + msg = parse_opts(ac, av, NULL, NULL); + if (msg != NULL) + tst_brkm(TBROK, NULL, "OPTION PARSING ERROR - %s", msg); + + setup(); + + child = tst_fork(); + if (child < 0) + tst_brkm(TBROK | TERRNO, cleanup, "fork failed"); + + if (child == 0) + do_child(); + + while (1) { + SAFE_GETCWD(cleanup, cur_cwd, PATH_MAX); + if (strncmp(init_cwd, cur_cwd, PATH_MAX)) { + tst_resm(TFAIL, "initial current work directory is " + "%s, now is %s. Bug is reproduced!", + init_cwd, cur_cwd); + break; + } + + if (end) { + tst_resm(TPASS, "Bug is not reproduced!"); + break; + } + } + + SAFE_KILL(cleanup, child, SIGKILL); + SAFE_WAITPID(cleanup, child, &status, 0); + + cleanup(); + tst_exit(); +} + +static void setup(void) +{ + tst_sig(FORK, DEF_HANDLER, cleanup); + + TEST_PAUSE; + + tst_tmpdir(); + + if (signal(SIGALRM, sigproc) == SIG_ERR) + tst_brkm(TBROK | TERRNO, cleanup, "signal(SIGALRM) failed"); + + alarm(TIMEOUT); + + SAFE_MKDIR(cleanup, "testdir", 0755); + SAFE_CHDIR(cleanup, "testdir"); + + SAFE_GETCWD(cleanup, init_cwd, PATH_MAX); +} + +static void sigproc(int sig) +{ + end = sig; +} + +static void do_child(void) +{ + unsigned int i = 0; + char c_name[PATH_MAX] = "testfile", n_name[PATH_MAX]; + + SAFE_TOUCH(NULL, c_name, 0644, NULL); + + while (1) { + snprintf(n_name, PATH_MAX, "testfile%u", i++); + SAFE_RENAME(NULL, c_name, n_name); + strncpy(c_name, n_name, PATH_MAX); + } +} + +static void cleanup(void) +{ + TEST_CLEANUP; + + tst_rmdir(); +} -- 1.8.2.1 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-15 10:13 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang @ 2014-07-15 10:21 ` Xiaoguang Wang 2014-07-21 9:04 ` Jan Stancek 1 sibling, 0 replies; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-15 10:21 UTC (permalink / raw) To: LTP Hi, I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 and 3.16.0-rc4+. RHEL7.0GA has this kernel bug, so this test case fails. v3.11-7758-g232d2d6 has this bug, so this test case fails. Fedora19 does not contain this bug, so this test case succeeds. 3.16.0-rc4+ has this bug fixed, so this test case also succeeds. Regards, Xiaoguang Wang On 07/15/2014 06:13 PM, Xiaoguang Wang wrote: > Note: this test has already been in xfstests generic/028 test case, > I just port it to LTP. > > Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race > condition that causes getcwd(2) to return "/" instead of correct path. > 232d2d6 dcache: Translating dentry into pathname without > taking rename_lock > > And these two kernel commits have fixed this bug: > ede4cebce16f5643c61aedd6d88d9070a1d23a68 > prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts > f6500801522c61782d4990fa1ad96154cb397cd4 > f650080 __dentry_path() fixes > > This test is to check whether this bug exists in the running kernel, > or whether this bug has been fixed. > > Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > --- > runtest/ltplite | 1 + > runtest/stress.part3 | 1 + > runtest/syscalls | 1 + > testcases/kernel/syscalls/.gitignore | 1 + > testcases/kernel/syscalls/getcwd/getcwd04.c | 143 ++++++++++++++++++++++++++++ > 5 files changed, 147 insertions(+) > create mode 100644 testcases/kernel/syscalls/getcwd/getcwd04.c > > diff --git a/runtest/ltplite b/runtest/ltplite > index 50653a9..1457908 100644 > --- a/runtest/ltplite > +++ b/runtest/ltplite > @@ -275,6 +275,7 @@ getcontext01 getcontext01 > getcwd01 getcwd01 > getcwd02 getcwd02 > getcwd03 getcwd03 > +getcwd04 getcwd04 > > getdents01 getdents01 > getdents02 getdents02 > diff --git a/runtest/stress.part3 b/runtest/stress.part3 > index 39ce807..368c640 100644 > --- a/runtest/stress.part3 > +++ b/runtest/stress.part3 > @@ -214,6 +214,7 @@ getcontext01 getcontext01 > getcwd01 getcwd01 > getcwd02 getcwd02 > getcwd03 getcwd03 > +getcwd04 getcwd04 > > getdents01 getdents01 > getdents02 getdents02 > diff --git a/runtest/syscalls b/runtest/syscalls > index fbed9cb..13218e3 100644 > --- a/runtest/syscalls > +++ b/runtest/syscalls > @@ -329,6 +329,7 @@ getcpu01 getcpu01 > getcwd01 getcwd01 > getcwd02 getcwd02 > getcwd03 getcwd03 > +getcwd04 getcwd04 > > getdents01 getdents01 > getdents02 getdents02 > diff --git a/testcases/kernel/syscalls/.gitignore b/testcases/kernel/syscalls/.gitignore > index b9d49cf..fd3282b 100644 > --- a/testcases/kernel/syscalls/.gitignore > +++ b/testcases/kernel/syscalls/.gitignore > @@ -273,6 +273,7 @@ > /getcwd/getcwd01 > /getcwd/getcwd02 > /getcwd/getcwd03 > +/getcwd/getcwd04 > /getdents/getdents01 > /getdents/getdents01_64 > /getdents/getdents02 > diff --git a/testcases/kernel/syscalls/getcwd/getcwd04.c b/testcases/kernel/syscalls/getcwd/getcwd04.c > new file mode 100644 > index 0000000..a0285cb > --- /dev/null > +++ b/testcases/kernel/syscalls/getcwd/getcwd04.c > @@ -0,0 +1,143 @@ > +/* > + * Copyright (c) 2014 Fujitsu Ltd. > + * Author: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See > + * the GNU General Public License for more details. > + */ > + > +/* > + * Note: this test has already been in xfstests generic/028 test case, > + * I just port it to LTP. > + * > + * Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race > + * condition that causes getcwd(2) to return "/" instead of correct path. > + * 232d2d6 dcache: Translating dentry into pathname without > + * taking rename_lock > + * > + * And these two kernel commits fixed the bug: > + * ede4cebce16f5643c61aedd6d88d9070a1d23a68 > + * prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts > + * f6500801522c61782d4990fa1ad96154cb397cd4 > + * f650080 __dentry_path() fixes > + * > + * This test is to check whether this bug exists in the running kernel, > + * or whether this bug has been fixed. > + * > + */ > + > +#include <stdio.h> > +#include <errno.h> > +#include <fcntl.h> > +#include <sys/types.h> > +#include <unistd.h> > + > +#include "usctest.h" > +#include "test.h" > +#include "safe_macros.h" > + > +#define TIMEOUT 5 > + > +static void setup(void); > +static void cleanup(void); > +static void do_child(void); > +static void sigproc(int sig); > +static volatile sig_atomic_t end; > +static char init_cwd[PATH_MAX]; > + > +char *TCID = "getcwd04"; > +int TST_TOTAL = 1; > + > +int main(int ac, char **av) > +{ > + int status; > + const char *msg; > + char cur_cwd[PATH_MAX]; > + pid_t child; > + > + msg = parse_opts(ac, av, NULL, NULL); > + if (msg != NULL) > + tst_brkm(TBROK, NULL, "OPTION PARSING ERROR - %s", msg); > + > + setup(); > + > + child = tst_fork(); > + if (child < 0) > + tst_brkm(TBROK | TERRNO, cleanup, "fork failed"); > + > + if (child == 0) > + do_child(); > + > + while (1) { > + SAFE_GETCWD(cleanup, cur_cwd, PATH_MAX); > + if (strncmp(init_cwd, cur_cwd, PATH_MAX)) { > + tst_resm(TFAIL, "initial current work directory is " > + "%s, now is %s. Bug is reproduced!", > + init_cwd, cur_cwd); > + break; > + } > + > + if (end) { > + tst_resm(TPASS, "Bug is not reproduced!"); > + break; > + } > + } > + > + SAFE_KILL(cleanup, child, SIGKILL); > + SAFE_WAITPID(cleanup, child, &status, 0); > + > + cleanup(); > + tst_exit(); > +} > + > +static void setup(void) > +{ > + tst_sig(FORK, DEF_HANDLER, cleanup); > + > + TEST_PAUSE; > + > + tst_tmpdir(); > + > + if (signal(SIGALRM, sigproc) == SIG_ERR) > + tst_brkm(TBROK | TERRNO, cleanup, "signal(SIGALRM) failed"); > + > + alarm(TIMEOUT); > + > + SAFE_MKDIR(cleanup, "testdir", 0755); > + SAFE_CHDIR(cleanup, "testdir"); > + > + SAFE_GETCWD(cleanup, init_cwd, PATH_MAX); > +} > + > +static void sigproc(int sig) > +{ > + end = sig; > +} > + > +static void do_child(void) > +{ > + unsigned int i = 0; > + char c_name[PATH_MAX] = "testfile", n_name[PATH_MAX]; > + > + SAFE_TOUCH(NULL, c_name, 0644, NULL); > + > + while (1) { > + snprintf(n_name, PATH_MAX, "testfile%u", i++); > + SAFE_RENAME(NULL, c_name, n_name); > + strncpy(c_name, n_name, PATH_MAX); > + } > +} > + > +static void cleanup(void) > +{ > + TEST_CLEANUP; > + > + tst_rmdir(); > +} > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-15 10:13 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang 2014-07-15 10:21 ` Xiaoguang Wang @ 2014-07-21 9:04 ` Jan Stancek 2014-07-21 9:09 ` Wanlong Gao 1 sibling, 1 reply; 13+ messages in thread From: Jan Stancek @ 2014-07-21 9:04 UTC (permalink / raw) To: Xiaoguang Wang; +Cc: ltp-list, Artem Savkov ----- Original Message ----- > From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> > To: ltp-list@lists.sourceforge.net > Sent: Tuesday, 15 July, 2014 12:13:49 PM > Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) > > Note: this test has already been in xfstests generic/028 test case, > I just port it to LTP. > > Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race > condition that causes getcwd(2) to return "/" instead of correct path. > 232d2d6 dcache: Translating dentry into pathname without > taking rename_lock > > And these two kernel commits have fixed this bug: > ede4cebce16f5643c61aedd6d88d9070a1d23a68 > prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts > f6500801522c61782d4990fa1ad96154cb397cd4 > f650080 __dentry_path() fixes > > This test is to check whether this bug exists in the running kernel, > or whether this bug has been fixed. > > Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> Hi, looks good to me. > I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 and 3.16.0-rc4+. > RHEL7.0GA has this kernel bug, so this test case fails. I can confirm this, with note that I've seen it happen only on systems with 2+ CPUs. > + * > + */ > + > +#include <stdio.h> > +#include <errno.h> > +#include <fcntl.h> > +#include <sys/types.h> > +#include <unistd.h> > + > +#include "usctest.h" > +#include "test.h" > +#include "safe_macros.h" > + > +#define TIMEOUT 5 > + > +static void setup(void); > +static void cleanup(void); > +static void do_child(void); > +static void sigproc(int sig); > +static volatile sig_atomic_t end; > +static char init_cwd[PATH_MAX]; > + > +char *TCID = "getcwd04"; > +int TST_TOTAL = 1; > + > +int main(int ac, char **av) > +{ > + int status; > + const char *msg; > + char cur_cwd[PATH_MAX]; > + pid_t child; > + > + msg = parse_opts(ac, av, NULL, NULL); > + if (msg != NULL) > + tst_brkm(TBROK, NULL, "OPTION PARSING ERROR - %s", msg); > + > + setup(); > + > + child = tst_fork(); > + if (child < 0) > + tst_brkm(TBROK | TERRNO, cleanup, "fork failed"); > + > + if (child == 0) > + do_child(); > + > + while (1) { > + SAFE_GETCWD(cleanup, cur_cwd, PATH_MAX); > + if (strncmp(init_cwd, cur_cwd, PATH_MAX)) { > + tst_resm(TFAIL, "initial current work directory is " > + "%s, now is %s. Bug is reproduced!", > + init_cwd, cur_cwd); > + break; > + } > + > + if (end) { > + tst_resm(TPASS, "Bug is not reproduced!"); > + break; > + } > + } > + > + SAFE_KILL(cleanup, child, SIGKILL); > + SAFE_WAITPID(cleanup, child, &status, 0); > + > + cleanup(); > + tst_exit(); > +} > + > +static void setup(void) > +{ > + tst_sig(FORK, DEF_HANDLER, cleanup); > + > + TEST_PAUSE; > + > + tst_tmpdir(); > + > + if (signal(SIGALRM, sigproc) == SIG_ERR) > + tst_brkm(TBROK | TERRNO, cleanup, "signal(SIGALRM) failed"); > + > + alarm(TIMEOUT); > + > + SAFE_MKDIR(cleanup, "testdir", 0755); > + SAFE_CHDIR(cleanup, "testdir"); Is this extra dir needed? tst_tmpdir will already make one. Regards, Jan > + > + SAFE_GETCWD(cleanup, init_cwd, PATH_MAX); > +} > + > +static void sigproc(int sig) > +{ > + end = sig; > +} > + > +static void do_child(void) > +{ > + unsigned int i = 0; > + char c_name[PATH_MAX] = "testfile", n_name[PATH_MAX]; > + > + SAFE_TOUCH(NULL, c_name, 0644, NULL); > + > + while (1) { > + snprintf(n_name, PATH_MAX, "testfile%u", i++); > + SAFE_RENAME(NULL, c_name, n_name); > + strncpy(c_name, n_name, PATH_MAX); > + } > +} > + > +static void cleanup(void) > +{ > + TEST_CLEANUP; > + > + tst_rmdir(); > +} > -- > 1.8.2.1 > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Ltp-list mailing list > Ltp-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ltp-list > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:04 ` Jan Stancek @ 2014-07-21 9:09 ` Wanlong Gao 2014-07-21 9:23 ` Xiaoguang Wang 2014-07-21 9:33 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Jan Stancek 0 siblings, 2 replies; 13+ messages in thread From: Wanlong Gao @ 2014-07-21 9:09 UTC (permalink / raw) To: Jan Stancek, Xiaoguang Wang; +Cc: ltp-list, Artem Savkov On 07/21/2014 05:04 PM, Jan Stancek wrote: > > > ----- Original Message ----- >> > From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> >> > To: ltp-list@lists.sourceforge.net >> > Sent: Tuesday, 15 July, 2014 12:13:49 PM >> > Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) >> > >> > Note: this test has already been in xfstests generic/028 test case, >> > I just port it to LTP. >> > >> > Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race >> > condition that causes getcwd(2) to return "/" instead of correct path. >> > 232d2d6 dcache: Translating dentry into pathname without >> > taking rename_lock >> > >> > And these two kernel commits have fixed this bug: >> > ede4cebce16f5643c61aedd6d88d9070a1d23a68 >> > prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts >> > f6500801522c61782d4990fa1ad96154cb397cd4 >> > f650080 __dentry_path() fixes >> > >> > This test is to check whether this bug exists in the running kernel, >> > or whether this bug has been fixed. >> > >> > Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > Hi, > > looks good to me. > >> > I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 and 3.16.0-rc4+. >> > RHEL7.0GA has this kernel bug, so this test case fails. > I can confirm this, with note that I've seen it happen only on systems with 2+ CPUs. If this note is truth, we should judge the nr_cpus in this case to make sure it always gives the right result. Thanks, Wanlong Gao ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:09 ` Wanlong Gao @ 2014-07-21 9:23 ` Xiaoguang Wang 2014-07-27 8:42 ` Xiaoguang Wang 2014-07-21 9:33 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Jan Stancek 1 sibling, 1 reply; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-21 9:23 UTC (permalink / raw) To: gaowanlong; +Cc: Artem, ltp-list, Savkov Hi Jan, Wanlong, On 07/21/2014 05:09 PM, Wanlong Gao wrote: > On 07/21/2014 05:04 PM, Jan Stancek wrote: >> >> looks good to me. >> >>>> I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 and 3.16.0-rc4+. >>>> RHEL7.0GA has this kernel bug, so this test case fails. >> I can confirm this, with note that I've seen it happen only on systems with 2+ CPUs. > > If this note is truth, we should judge the nr_cpus in this case to make sure it always > gives the right result. Thanks Jan for pointing this. I'll have a look at these three related kernel patches again. If needed, I'll sent a v2 version including the judgment about number of cpus, thanks! Regards, Xiaoguang Wang > > Thanks, > Wanlong Gao > > > . > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:23 ` Xiaoguang Wang @ 2014-07-27 8:42 ` Xiaoguang Wang 2014-07-27 9:00 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Xiaoguang Wang 0 siblings, 1 reply; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-27 8:42 UTC (permalink / raw) To: gaowanlong; +Cc: ltp-list, Savkov, Artem Hi, On 07/21/2014 05:23 PM, Xiaoguang Wang wrote: > Hi Jan, Wanlong, > > On 07/21/2014 05:09 PM, Wanlong Gao wrote: >> On 07/21/2014 05:04 PM, Jan Stancek wrote: >>> >>> looks good to me. >>> >>>>> I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 and 3.16.0-rc4+. >>>>> RHEL7.0GA has this kernel bug, so this test case fails. >>> I can confirm this, with note that I've seen it happen only on systems with 2+ CPUs. >> >> If this note is truth, we should judge the nr_cpus in this case to make sure it always >> gives the right result. > > Thanks Jan for pointing this. > I'll have a look at these three related kernel patches again. If needed, I'll sent a > v2 version including the judgment about number of cpus, thanks! I'm not that familiar with kernel VFS layer code and spent time to look into the code, sorry for the delay. Now I think it is impossible to reproduce this bug in only one cpu machine, below is the possible reason, please check it(The kernel source code I used is RHEL7.0GA). First let me explain why this bug is triggered. Look at the getcwd(2)'s implementation, SYSCALL_DEFINE2(getcwd, ...) ----prepend_path(...) In prepend_path(), it will use a kernel sequence lock named rename_lock to check whether the corresponding operation in prepend_path() is valid. If it's valid, everything is OK. But if it's not(for example, some other kernel code flow call a write_seqlock() on the rename_lock), then prepend_path() need to restart the entire operation, but kernel commit 232d2d6 patch forgot to reinitialize dentry/vfsmount/mnt, in this time, the dentry is already the root dentry, so gewcwd(2) will return a "/", bug is triggered. But when we only have one cpu, when we are in prepend_path(), If I understand right, I think there is no operation in prepend_path() that will cause the current kernel code flow to sleep or give up the cpu voluntarily and kernel is preempt disabled, only when the getcwd(2) operation completes, can a process switch happen when returning to user space, that says we can ensure there is no other kernel code flow have a chance to operate rename_lock in kernel when a getcwd(2) is in progress. So I'll send a V2 patch including the judgment about number of cpus. If system only has one cpu, it will print a TCONF, thanks! Regards, Xiaoguang Wang > > Regards, > Xiaoguang Wang >> >> Thanks, >> Wanlong Gao >> >> >> . >> > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Ltp-list mailing list > Ltp-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ltp-list > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() 2014-07-27 8:42 ` Xiaoguang Wang @ 2014-07-27 9:00 ` Xiaoguang Wang 2014-07-27 9:00 ` [LTP] [PATCH v2 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang 2014-08-01 1:51 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Wanlong Gao 0 siblings, 2 replies; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-27 9:00 UTC (permalink / raw) To: ltp-list Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> --- include/safe_macros.h | 5 +++++ lib/safe_macros.c | 16 ++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/include/safe_macros.h b/include/safe_macros.h index f521347..a79c4ad 100644 --- a/include/safe_macros.h +++ b/include/safe_macros.h @@ -266,5 +266,10 @@ int safe_mkfifo(const char *file, const int lineno, #define SAFE_MKFIFO(cleanup_fn, pathname, mode) \ safe_mkfifo(__FILE__, __LINE__, (cleanup_fn), (pathname), (mode)) +int safe_rename(const char *file, const int lineno, void (*cleanup_fn)(void), + const char *oldpath, const char *newpath); +#define SAFE_RENAME(cleanup_fn, oldpath, newpath) \ + safe_rename(__FILE__, __LINE__, (cleanup_fn), (oldpath), (newpath)) + #endif /* __SAFE_MACROS_H__ */ #endif /* __TEST_H__ */ diff --git a/lib/safe_macros.c b/lib/safe_macros.c index a07cffa..eefacae 100644 --- a/lib/safe_macros.c +++ b/lib/safe_macros.c @@ -768,3 +768,19 @@ int safe_mkfifo(const char *file, const int lineno, return rval; } + +int safe_rename(const char *file, const int lineno, void (*cleanup_fn)(void), + const char *oldpath, const char *newpath) +{ + int rval; + + rval = rename(oldpath, newpath); + + if (rval == -1) { + tst_brkm(TBROK | TERRNO, cleanup_fn, + "%s:%d: rename(%s, %s) failed", + file, lineno, oldpath, newpath); + } + + return rval; +} -- 1.8.2.1 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [LTP] [PATCH v2 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-27 9:00 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Xiaoguang Wang @ 2014-07-27 9:00 ` Xiaoguang Wang 2014-08-01 1:51 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Wanlong Gao 1 sibling, 0 replies; 13+ messages in thread From: Xiaoguang Wang @ 2014-07-27 9:00 UTC (permalink / raw) To: ltp-list Note: this test has already been in xfstests generic/028 test case, I just port it to LTP. And this bug is hard or impossible to reprodeced in a single cpu machine. Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race condition that causes getcwd(2) to return "/" instead of correct path. 232d2d6 dcache: Translating dentry into pathname without taking rename_lock And these two kernel commits have fixed this bug: ede4cebce16f5643c61aedd6d88d9070a1d23a68 prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts f6500801522c61782d4990fa1ad96154cb397cd4 f650080 __dentry_path() fixes This test is to check whether this bug exists in the running kernel, or whether this bug has been fixed. Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> --- runtest/ltplite | 1 + runtest/stress.part3 | 1 + runtest/syscalls | 1 + testcases/kernel/syscalls/.gitignore | 1 + testcases/kernel/syscalls/getcwd/getcwd04.c | 143 ++++++++++++++++++++++++++++ 5 files changed, 147 insertions(+) create mode 100644 testcases/kernel/syscalls/getcwd/getcwd04.c diff --git a/runtest/ltplite b/runtest/ltplite index 50653a9..1457908 100644 --- a/runtest/ltplite +++ b/runtest/ltplite @@ -275,6 +275,7 @@ getcontext01 getcontext01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/runtest/stress.part3 b/runtest/stress.part3 index 39ce807..368c640 100644 --- a/runtest/stress.part3 +++ b/runtest/stress.part3 @@ -214,6 +214,7 @@ getcontext01 getcontext01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/runtest/syscalls b/runtest/syscalls index aa6b977..5e6e0f4 100644 --- a/runtest/syscalls +++ b/runtest/syscalls @@ -329,6 +329,7 @@ getcpu01 getcpu01 getcwd01 getcwd01 getcwd02 getcwd02 getcwd03 getcwd03 +getcwd04 getcwd04 getdents01 getdents01 getdents02 getdents02 diff --git a/testcases/kernel/syscalls/.gitignore b/testcases/kernel/syscalls/.gitignore index 9487cc9..fb2425e 100644 --- a/testcases/kernel/syscalls/.gitignore +++ b/testcases/kernel/syscalls/.gitignore @@ -273,6 +273,7 @@ /getcwd/getcwd01 /getcwd/getcwd02 /getcwd/getcwd03 +/getcwd/getcwd04 /getdents/getdents01 /getdents/getdents01_64 /getdents/getdents02 diff --git a/testcases/kernel/syscalls/getcwd/getcwd04.c b/testcases/kernel/syscalls/getcwd/getcwd04.c new file mode 100644 index 0000000..844f301 --- /dev/null +++ b/testcases/kernel/syscalls/getcwd/getcwd04.c @@ -0,0 +1,143 @@ +/* + * Copyright (c) 2014 Fujitsu Ltd. + * Author: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See + * the GNU General Public License for more details. + */ + +/* + * Note: this test has already been in xfstests generic/028 test case, + * I just port it to LTP. + * + * Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a race + * condition that causes getcwd(2) to return "/" instead of correct path. + * 232d2d6 dcache: Translating dentry into pathname without + * taking rename_lock + * + * And these two kernel commits fixed the bug: + * ede4cebce16f5643c61aedd6d88d9070a1d23a68 + * prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts + * f6500801522c61782d4990fa1ad96154cb397cd4 + * f650080 __dentry_path() fixes + * + * This test is to check whether this bug exists in the running kernel, + * or whether this bug has been fixed. + * + */ + +#include <stdio.h> +#include <errno.h> +#include <fcntl.h> +#include <sys/types.h> +#include <unistd.h> + +#include "usctest.h" +#include "test.h" +#include "safe_macros.h" + +#define TIMEOUT 5 + +static void setup(void); +static void cleanup(void); +static void do_child(void); +static void sigproc(int sig); +static volatile sig_atomic_t end; +static char init_cwd[PATH_MAX]; + +char *TCID = "getcwd04"; +int TST_TOTAL = 1; + +int main(int ac, char **av) +{ + int status; + const char *msg; + char cur_cwd[PATH_MAX]; + pid_t child; + + msg = parse_opts(ac, av, NULL, NULL); + if (msg != NULL) + tst_brkm(TBROK, NULL, "OPTION PARSING ERROR - %s", msg); + + setup(); + + child = tst_fork(); + if (child < 0) + tst_brkm(TBROK | TERRNO, cleanup, "fork failed"); + + if (child == 0) + do_child(); + + while (1) { + SAFE_GETCWD(cleanup, cur_cwd, PATH_MAX); + if (strncmp(init_cwd, cur_cwd, PATH_MAX)) { + tst_resm(TFAIL, "initial current work directory is " + "%s, now is %s. Bug is reproduced!", + init_cwd, cur_cwd); + break; + } + + if (end) { + tst_resm(TPASS, "Bug is not reproduced!"); + break; + } + } + + SAFE_KILL(cleanup, child, SIGKILL); + SAFE_WAITPID(cleanup, child, &status, 0); + + cleanup(); + tst_exit(); +} + +static void setup(void) +{ + tst_sig(FORK, DEF_HANDLER, cleanup); + + TEST_PAUSE; + + if (tst_ncpus() == 1) + tst_brkm(TCONF, NULL, "This test needs two cpus at least"); + + tst_tmpdir(); + + if (signal(SIGALRM, sigproc) == SIG_ERR) + tst_brkm(TBROK | TERRNO, cleanup, "signal(SIGALRM) failed"); + + alarm(TIMEOUT); + + SAFE_GETCWD(cleanup, init_cwd, PATH_MAX); +} + +static void sigproc(int sig) +{ + end = sig; +} + +static void do_child(void) +{ + unsigned int i = 0; + char c_name[PATH_MAX] = "testfile", n_name[PATH_MAX]; + + SAFE_TOUCH(NULL, c_name, 0644, NULL); + + while (1) { + snprintf(n_name, PATH_MAX, "testfile%u", i++); + SAFE_RENAME(NULL, c_name, n_name); + strncpy(c_name, n_name, PATH_MAX); + } +} + +static void cleanup(void) +{ + TEST_CLEANUP; + + tst_rmdir(); +} -- 1.8.2.1 ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() 2014-07-27 9:00 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Xiaoguang Wang 2014-07-27 9:00 ` [LTP] [PATCH v2 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang @ 2014-08-01 1:51 ` Wanlong Gao 1 sibling, 0 replies; 13+ messages in thread From: Wanlong Gao @ 2014-08-01 1:51 UTC (permalink / raw) To: Xiaoguang Wang; +Cc: ltp-list On 07/27/2014 05:00 PM, Xiaoguang Wang wrote: > Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > --- > include/safe_macros.h | 5 +++++ > lib/safe_macros.c | 16 ++++++++++++++++ > 2 files changed, 21 insertions(+) Applied the series, thank you and Jan's test-review. Wanlong Gao ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:09 ` Wanlong Gao 2014-07-21 9:23 ` Xiaoguang Wang @ 2014-07-21 9:33 ` Jan Stancek 2014-07-21 9:40 ` Wanlong Gao 1 sibling, 1 reply; 13+ messages in thread From: Jan Stancek @ 2014-07-21 9:33 UTC (permalink / raw) To: gaowanlong; +Cc: Artem Savkov, ltp-list ----- Original Message ----- > From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com> > To: "Jan Stancek" <jstancek@redhat.com>, "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> > Cc: ltp-list@lists.sourceforge.net, "Artem Savkov" <asavkov@redhat.com> > Sent: Monday, 21 July, 2014 11:09:47 AM > Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) > > On 07/21/2014 05:04 PM, Jan Stancek wrote: > > > > > > ----- Original Message ----- > >> > From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> > >> > To: ltp-list@lists.sourceforge.net > >> > Sent: Tuesday, 15 July, 2014 12:13:49 PM > >> > Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for > >> > getcwd(2) > >> > > >> > Note: this test has already been in xfstests generic/028 test case, > >> > I just port it to LTP. > >> > > >> > Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a > >> > race > >> > condition that causes getcwd(2) to return "/" instead of correct path. > >> > 232d2d6 dcache: Translating dentry into pathname without > >> > taking rename_lock > >> > > >> > And these two kernel commits have fixed this bug: > >> > ede4cebce16f5643c61aedd6d88d9070a1d23a68 > >> > prepend_path() needs to reinitialize dentry/vfsmount/mnt on > >> > restarts > >> > f6500801522c61782d4990fa1ad96154cb397cd4 > >> > f650080 __dentry_path() fixes > >> > > >> > This test is to check whether this bug exists in the running kernel, > >> > or whether this bug has been fixed. > >> > > >> > Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > > Hi, > > > > looks good to me. > > > >> > I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 > >> > and 3.16.0-rc4+. > >> > RHEL7.0GA has this kernel bug, so this test case fails. > > I can confirm this, with note that I've seen it happen only on systems with > > 2+ CPUs. > > If this note is truth, we should judge the nr_cpus in this case to make sure > it always > gives the right result. My observation is that it's at least easier to reproduce on 2+ CPUs: # time taskset -c 0 ./getcwd04 getcwd04 1 TPASS : Bug is not reproduced! real 0m5.002s user 0m0.506s sys 0m4.494s # time taskset -c 0,1 ./getcwd04 getcwd04 1 TFAIL : initial current work directory is /tmp/getg6foNN/testdir, now is /. Bug is reproduced! real 0m0.002s user 0m0.000s sys 0m0.002s I'm not sure what you are suggesting we do, other than to make note somewhere. It's a test for race condition, so if it tried its best to reproduce and ended with "Bug is not reproduced!", that looks like right result to me. Regards, Jan > > Thanks, > Wanlong Gao > > > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:33 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Jan Stancek @ 2014-07-21 9:40 ` Wanlong Gao 2014-07-21 9:58 ` Jan Stancek 0 siblings, 1 reply; 13+ messages in thread From: Wanlong Gao @ 2014-07-21 9:40 UTC (permalink / raw) To: Jan Stancek; +Cc: Artem Savkov, ltp-list On 07/21/2014 05:33 PM, Jan Stancek wrote: > > > ----- Original Message ----- >> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com> >> To: "Jan Stancek" <jstancek@redhat.com>, "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> >> Cc: ltp-list@lists.sourceforge.net, "Artem Savkov" <asavkov@redhat.com> >> Sent: Monday, 21 July, 2014 11:09:47 AM >> Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) >> >> On 07/21/2014 05:04 PM, Jan Stancek wrote: >>> >>> >>> ----- Original Message ----- >>>>> From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> >>>>> To: ltp-list@lists.sourceforge.net >>>>> Sent: Tuesday, 15 July, 2014 12:13:49 PM >>>>> Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for >>>>> getcwd(2) >>>>> >>>>> Note: this test has already been in xfstests generic/028 test case, >>>>> I just port it to LTP. >>>>> >>>>> Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a >>>>> race >>>>> condition that causes getcwd(2) to return "/" instead of correct path. >>>>> 232d2d6 dcache: Translating dentry into pathname without >>>>> taking rename_lock >>>>> >>>>> And these two kernel commits have fixed this bug: >>>>> ede4cebce16f5643c61aedd6d88d9070a1d23a68 >>>>> prepend_path() needs to reinitialize dentry/vfsmount/mnt on >>>>> restarts >>>>> f6500801522c61782d4990fa1ad96154cb397cd4 >>>>> f650080 __dentry_path() fixes >>>>> >>>>> This test is to check whether this bug exists in the running kernel, >>>>> or whether this bug has been fixed. >>>>> >>>>> Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> >>> Hi, >>> >>> looks good to me. >>> >>>>> I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 >>>>> and 3.16.0-rc4+. >>>>> RHEL7.0GA has this kernel bug, so this test case fails. >>> I can confirm this, with note that I've seen it happen only on systems with >>> 2+ CPUs. >> >> If this note is truth, we should judge the nr_cpus in this case to make sure >> it always >> gives the right result. > > My observation is that it's at least easier to reproduce on 2+ CPUs: > > # time taskset -c 0 ./getcwd04 > getcwd04 1 TPASS : Bug is not reproduced! > > real 0m5.002s > user 0m0.506s > sys 0m4.494s > > # time taskset -c 0,1 ./getcwd04 > getcwd04 1 TFAIL : initial current work directory is /tmp/getg6foNN/testdir, now is /. Bug is reproduced! > > real 0m0.002s > user 0m0.000s > sys 0m0.002s > > > I'm not sure what you are suggesting we do, other than to make note somewhere. > > It's a test for race condition, so if it tried its best to reproduce and > ended with "Bug is not reproduced!", that looks like right result to me. I mean if we can't reproduce the bug on the system with less-than-2-cpus, we may need to give a note? Since this not means the kernel doesn't have this bug but not reproduced on this specific hardware, right? Thanks, Wanlong Gao > > Regards, > Jan > >> >> Thanks, >> Wanlong Gao >> >> >> > . > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) 2014-07-21 9:40 ` Wanlong Gao @ 2014-07-21 9:58 ` Jan Stancek 0 siblings, 0 replies; 13+ messages in thread From: Jan Stancek @ 2014-07-21 9:58 UTC (permalink / raw) To: gaowanlong; +Cc: Artem Savkov, ltp-list ----- Original Message ----- > From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com> > To: "Jan Stancek" <jstancek@redhat.com> > Cc: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com>, ltp-list@lists.sourceforge.net, "Artem Savkov" > <asavkov@redhat.com> > Sent: Monday, 21 July, 2014 11:40:19 AM > Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) > > On 07/21/2014 05:33 PM, Jan Stancek wrote: > > > > > > ----- Original Message ----- > >> From: "Wanlong Gao" <gaowanlong@cn.fujitsu.com> > >> To: "Jan Stancek" <jstancek@redhat.com>, "Xiaoguang Wang" > >> <wangxg.fnst@cn.fujitsu.com> > >> Cc: ltp-list@lists.sourceforge.net, "Artem Savkov" <asavkov@redhat.com> > >> Sent: Monday, 21 July, 2014 11:09:47 AM > >> Subject: Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for > >> getcwd(2) > >> > >> On 07/21/2014 05:04 PM, Jan Stancek wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>>> From: "Xiaoguang Wang" <wangxg.fnst@cn.fujitsu.com> > >>>>> To: ltp-list@lists.sourceforge.net > >>>>> Sent: Tuesday, 15 July, 2014 12:13:49 PM > >>>>> Subject: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for > >>>>> getcwd(2) > >>>>> > >>>>> Note: this test has already been in xfstests generic/028 test case, > >>>>> I just port it to LTP. > >>>>> > >>>>> Kernel commit '232d2d60aa5469bb097f55728f65146bd49c1d25' introduced a > >>>>> race > >>>>> condition that causes getcwd(2) to return "/" instead of correct path. > >>>>> 232d2d6 dcache: Translating dentry into pathname without > >>>>> taking rename_lock > >>>>> > >>>>> And these two kernel commits have fixed this bug: > >>>>> ede4cebce16f5643c61aedd6d88d9070a1d23a68 > >>>>> prepend_path() needs to reinitialize dentry/vfsmount/mnt on > >>>>> restarts > >>>>> f6500801522c61782d4990fa1ad96154cb397cd4 > >>>>> f650080 __dentry_path() fixes > >>>>> > >>>>> This test is to check whether this bug exists in the running kernel, > >>>>> or whether this bug has been fixed. > >>>>> > >>>>> Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com> > >>> Hi, > >>> > >>> looks good to me. > >>> > >>>>> I have run this test case in RHEL7.0GA, Fedora19, v3.11-7758-g232d2d6 > >>>>> and 3.16.0-rc4+. > >>>>> RHEL7.0GA has this kernel bug, so this test case fails. > >>> I can confirm this, with note that I've seen it happen only on systems > >>> with > >>> 2+ CPUs. > >> > >> If this note is truth, we should judge the nr_cpus in this case to make > >> sure > >> it always > >> gives the right result. > > > > My observation is that it's at least easier to reproduce on 2+ CPUs: > > > > # time taskset -c 0 ./getcwd04 > > getcwd04 1 TPASS : Bug is not reproduced! > > > > real 0m5.002s > > user 0m0.506s > > sys 0m4.494s > > > > # time taskset -c 0,1 ./getcwd04 > > getcwd04 1 TFAIL : initial current work directory is > > /tmp/getg6foNN/testdir, now is /. Bug is reproduced! > > > > real 0m0.002s > > user 0m0.000s > > sys 0m0.002s > > > > > > I'm not sure what you are suggesting we do, other than to make note > > somewhere. > > > > It's a test for race condition, so if it tried its best to reproduce and > > ended with "Bug is not reproduced!", that looks like right result to me. > > I mean if we can't reproduce the bug on the system with less-than-2-cpus, > we may need to give a note? Since this not means the kernel doesn't have > this bug but not reproduced on this specific hardware, right? Sure. I have no objections on expanding "Bug is not reproduced!" message in case it runs on single CPU system to give more context. Regards, Jan > > Thanks, > Wanlong Gao > > > > > Regards, > > Jan > > > >> > >> Thanks, > >> Wanlong Gao > >> > >> > >> > > . > > > > ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-08-01 1:51 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-15 10:13 [LTP] [PATCH 1/2] lib: add SAFE_RENAME() Xiaoguang Wang 2014-07-15 10:13 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang 2014-07-15 10:21 ` Xiaoguang Wang 2014-07-21 9:04 ` Jan Stancek 2014-07-21 9:09 ` Wanlong Gao 2014-07-21 9:23 ` Xiaoguang Wang 2014-07-27 8:42 ` Xiaoguang Wang 2014-07-27 9:00 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Xiaoguang Wang 2014-07-27 9:00 ` [LTP] [PATCH v2 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Xiaoguang Wang 2014-08-01 1:51 ` [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME() Wanlong Gao 2014-07-21 9:33 ` [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2) Jan Stancek 2014-07-21 9:40 ` Wanlong Gao 2014-07-21 9:58 ` Jan Stancek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox