[LTP] [PATCH 1/2] lib: add SAFE_RENAME()

[LTP] [PATCH 1/2] lib: add SAFE_RENAME()

[Xiaoguang Wang]

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

[LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Xiaoguang Wang]

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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Xiaoguang Wang]

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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Jan Stancek]

----- 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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Wanlong Gao]

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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Xiaoguang Wang]

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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Jan Stancek]

----- 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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Wanlong Gao]

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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Jan Stancek]

----- 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

Re: [LTP] [PATCH 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Xiaoguang Wang]

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

[LTP] [PATCH v2 1/2] lib: add SAFE_RENAME()

[Xiaoguang Wang]

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

[LTP] [PATCH v2 2/2] syscalls/getcwd04.c: regression test for getcwd(2)

[Xiaoguang Wang]

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

Re: [LTP] [PATCH v2 1/2] lib: add SAFE_RENAME()

[Wanlong Gao]

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