syscalls/setrlimit: add setrlimit04

+ * DESCRIPTION
+ * Attempt to run a trivial binary with stack < 1MB.
+ *

+ *     Early patches for stack guard gap caused that gap size was
+ *     contributing towards stack limit. This caused failures
+ *     for new processes (E2BIG) when ulimit was set to anything
+ *     lower than size of gap. commit 1be7107fbe18 "mm: larger
+ *     stack guard gap, between vmas" sets default gap size to 1M
+ *     (for systems with 4k pages), so let's set stack limit to 512kB
+ *     and confirm we can still run some trivial binary.

+ */

testcases/kernel/syscalls/setrlimit/setrlimit04.c new file +43 -1

+
+#define _GNU_SOURCE
+#include <sys/resource.h>
+#include <sys/time.h>
+#include <sys/wait.h>
+
+#include "tst_test.h"
+
+#define STACK_LIMIT (512 * 1024)
+
+static void test_setrlimit(void)
+{
+	int status;
+	struct rlimit rlim;
+	pid_t child;
+
+	rlim.rlim_cur = STACK_LIMIT;
+	rlim.rlim_max = STACK_LIMIT;
+
+	SAFE_SETRLIMIT(RLIMIT_STACK, &rlim);
+
+	child = SAFE_FORK();
+	if (child == 0)
+		SAFE_EXECLP("/bin/true", "/bin/true", NULL);
+	SAFE_WAITPID(child, &status, 0);
+
+	if (WIFEXITED(status)) {
+		if ((WEXITSTATUS(status) == 0))
+			tst_res(TPASS, "child process completed OK");
+		else
+			tst_res(TFAIL, "child process exited with %d",
+				WEXITSTATUS(status));
+	} else if (WIFSIGNALED(status)) {
+		tst_res(TFAIL, "child exited with signal %s",
+			tst_strsig(WTERMSIG(status)));
+	}
+}
+
+static struct tst_test test = {
+	.test_all     = test_setrlimit,
+	.forks_child  = 1,
+	.needs_root = 1,
+};
--

1.8.3.1

Hi Jan,

Quoted 11 lines · Jan Stancek

+ * DESCRIPTION
+ * Attempt to run a trivial binary with stack < 1MB.
+ *

+ *     Early patches for stack guard gap caused that gap size was
+ *     contributing towards stack limit. This caused failures
+ *     for new processes (E2BIG) when ulimit was set to anything
+ *     lower than size of gap. commit 1be7107fbe18 "mm: larger
+ *     stack guard gap, between vmas" sets default gap size to 1M
+ *     (for systems with 4k pages), so let's set stack limit to 512kB
+ *     and confirm we can still run some trivial binary.

+ */

The first sentance is difficult to parse. I think you are saying that in the early patches the stack gaurd gap was included in the stack size.

The stack size is then compared to the stack limit, so a process would fail to start if

[initial process stack usage] + [stack gap] > [stack limit].

However the stack gap should not be included in this calculation.

Early patches for stack guard gap caused that gap size was contributing towards stack limit. This caused failures for new processes (E2BIG) when ulimit was set to anything lower than size of gap.

  # ./setrlimit04
  tst_test.c:898: INFO: Timeout per run is 0h 05m 00s
  setrlimit04.c:53: BROK: execlp(/bin/true, /bin/true, ...) failed: E2BIG
  setrlimit04.c:61: FAIL: child process exited with 2

commit 1be7107fbe18 "mm: larger stack guard gap, between vmas" sets default gap size to 1M (for systems with 4k pages), so let's set stack limit to 512kB and confirm we can still run some trivial binary.

Signed-off-by Jan Stancek <[email protected]>

---
 runtest/syscalls                                  |  1 +
 testcases/kernel/syscalls/.gitignore              |  1 +
 testcases/kernel/syscalls/setrlimit/setrlimit04.c | 67 +++++++++++++++++++++++
 3 files changed, 69 insertions(+)
 create mode 100644 testcases/kernel/syscalls/setrlimit/setrlimit04.c

runtest/syscalls +1 -0

index 91aba8504ef3..dddc7b0bee94 100644
@@ -1132,6 +1132,7 @@ setreuid07_16 setreuid07_16
 setrlimit01 setrlimit01
 setrlimit02 setrlimit02
 setrlimit03 setrlimit03
+setrlimit04 setrlimit04
 
 set_robust_list01 set_robust_list01
 set_thread_area01 set_thread_area01

testcases/kernel/syscalls/.gitignore +1 -0

index 3d9bb756c82b..1735cdab0860 100644
@@ -922,6 +922,7 @@
 /setrlimit/setrlimit01
 /setrlimit/setrlimit02
 /setrlimit/setrlimit03
+/setrlimit/setrlimit04
 /setsid/setsid01
 /setsockopt/setsockopt01
 /settimeofday/settimeofday01

testcases/kernel/syscalls/setrlimit/setrlimit04.c new file +56 -0

new file mode 100644
index 000000000000..13d1b9f98700
@@ -0,0 +1,67 @@
+/*
+ *   Copyright (C) 2017 Red Hat, Inc.  All rights reserved.
+ *
+ *   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.
+ *
+ *   DESCRIPTION
+ *     Attempt to run a trivial binary with stack < 1MB.
+ *
+ *     Early patches for stack guard gap caused that gap size was
+ *     contributing towards stack limit. This caused failures
+ *     for new processes (E2BIG) when ulimit was set to anything
+ *     lower than size of gap. commit 1be7107fbe18 "mm: larger
+ *     stack guard gap, between vmas" sets default gap size to 1M
+ *     (for systems with 4k pages), so let's set stack limit to 512kB
+ *     and confirm we can still run some trivial binary.
+ */
+
+#define _GNU_SOURCE
+#include <sys/resource.h>
+#include <sys/time.h>
+#include <sys/wait.h>
+
+#include "tst_test.h"
+
+#define STACK_LIMIT (512 * 1024)
+
+static void test_setrlimit(void)
+{
+       int status;
+       struct rlimit rlim;
+       pid_t child;
+
+       rlim.rlim_cur = STACK_LIMIT;
+       rlim.rlim_max = STACK_LIMIT;
+
+       SAFE_SETRLIMIT(RLIMIT_STACK, &rlim);
+
+       child = SAFE_FORK();
+       if (child == 0)
+               SAFE_EXECLP("/bin/true", "/bin/true", NULL);
+       SAFE_WAITPID(child, &status, 0);
+
+       if (WIFEXITED(status)) {
+               if ((WEXITSTATUS(status) == 0))
+                       tst_res(TPASS, "child process completed OK");
+               else
+                       tst_res(TFAIL, "child process exited with %d",
+                               WEXITSTATUS(status));

Quoted 3 lines

Early patches for stack guard gap caused that gap size was contributing towards stack limit. This caused failures for new processes (E2BIG) when ulimit was set to anything lower than size of gap.

testcases/kernel/syscalls/setrlimit/setrlimit04.c line 66

Quoted 4 lines

testcases/kernel/syscalls/setrlimit/setrlimit04.c new file +4 -0

+static struct tst_test test = {
+       .test_all     = test_setrlimit,
+       .forks_child  = 1,
+       .needs_root = 1,

seems we need to filter out the suitable kernel:

.min_kver = "4.12.0",

----- Original Message -----

Quoted 4 lines · Jan Stancek

Quoted 3 lines

Early patches for stack guard gap caused that gap size was contributing towards stack limit. This caused failures for new processes (E2BIG) when ulimit was set to anything lower than size of gap.

...

Quoted 5 lines

Quoted 4 lines

testcases/kernel/syscalls/setrlimit/setrlimit04.c new file +4 -0

+static struct tst_test test = {
+       .test_all     = test_setrlimit,
+       .forks_child  = 1,
+       .needs_root = 1,

Quoted 3 lines

seems we need to filter out the suitable kernel:

.min_kver = "4.12.0",

Why, shouldn't this work on any kernel version?

Quoted 13 lines

----- Original Message -----

Quoted 4 lines · Jan Stancek

Quoted 3 lines

Early patches for stack guard gap caused that gap size was contributing towards stack limit. This caused failures for new processes (E2BIG) when ulimit was set to anything lower than size of gap.

...

Quoted 5 lines

Quoted 4 lines

testcases/kernel/syscalls/setrlimit/setrlimit04.c new file +4 -0

+static struct tst_test test = {
+       .test_all     = test_setrlimit,
+       .forks_child  = 1,
+       .needs_root = 1,

Quoted 5 lines

Quoted 3 lines

seems we need to filter out the suitable kernel:

.min_kver = "4.12.0",

Why, shouldn't this work on any kernel version?

My bad. The "Early patches" has been reverted. I mistook this issue in versions.

You are right. please ignore my comments in last mail. :)

Another question come to my mind is that, if a system reboot with kernel parameter "stack_guard_gap=xxx", this case setrlimit04 still runs well and getting PASS, right?

Hi!
Looks good to me, acked.