* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
@ 2017-07-14 11:12 Jan Stancek
2017-07-14 12:45 ` Richard Palethorpe
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Jan Stancek @ 2017-07-14 11:12 UTC (permalink / raw)
To: ltp
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 <jstancek@redhat.com>
---
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
diff --git a/runtest/syscalls b/runtest/syscalls
index 91aba8504ef3..dddc7b0bee94 100644
--- a/runtest/syscalls
+++ b/runtest/syscalls
@@ -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
diff --git a/testcases/kernel/syscalls/.gitignore b/testcases/kernel/syscalls/.gitignore
index 3d9bb756c82b..1735cdab0860 100644
--- a/testcases/kernel/syscalls/.gitignore
+++ b/testcases/kernel/syscalls/.gitignore
@@ -922,6 +922,7 @@
/setrlimit/setrlimit01
/setrlimit/setrlimit02
/setrlimit/setrlimit03
+/setrlimit/setrlimit04
/setsid/setsid01
/setsockopt/setsockopt01
/settimeofday/settimeofday01
diff --git a/testcases/kernel/syscalls/setrlimit/setrlimit04.c b/testcases/kernel/syscalls/setrlimit/setrlimit04.c
new file mode 100644
index 000000000000..13d1b9f98700
--- /dev/null
+++ b/testcases/kernel/syscalls/setrlimit/setrlimit04.c
@@ -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));
+ } 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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-14 11:12 [LTP] [PATCH] syscalls/setrlimit: add setrlimit04 Jan Stancek
@ 2017-07-14 12:45 ` Richard Palethorpe
2017-07-17 7:01 ` Jan Stancek
2017-07-17 5:01 ` Li Wang
2017-10-02 13:11 ` Cyril Hrubis
2 siblings, 1 reply; 9+ messages in thread
From: Richard Palethorpe @ 2017-07-14 12:45 UTC (permalink / raw)
To: ltp
Hi Jan,
Jan Stancek writes:
> + * 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.
> +
> +#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
--
Thank you,
Richard.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-14 11:12 [LTP] [PATCH] syscalls/setrlimit: add setrlimit04 Jan Stancek
2017-07-14 12:45 ` Richard Palethorpe
@ 2017-07-17 5:01 ` Li Wang
2017-07-17 6:50 ` Jan Stancek
2017-10-02 13:11 ` Cyril Hrubis
2 siblings, 1 reply; 9+ messages in thread
From: Li Wang @ 2017-07-17 5:01 UTC (permalink / raw)
To: ltp
On Fri, Jul 14, 2017 at 7:12 PM, Jan Stancek <jstancek@redhat.com> wrote:
> 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 <jstancek@redhat.com>
> ---
> 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
>
> diff --git a/runtest/syscalls b/runtest/syscalls
> index 91aba8504ef3..dddc7b0bee94 100644
> --- a/runtest/syscalls
> +++ b/runtest/syscalls
> @@ -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
> diff --git a/testcases/kernel/syscalls/.gitignore b/testcases/kernel/syscalls/.gitignore
> index 3d9bb756c82b..1735cdab0860 100644
> --- a/testcases/kernel/syscalls/.gitignore
> +++ b/testcases/kernel/syscalls/.gitignore
> @@ -922,6 +922,7 @@
> /setrlimit/setrlimit01
> /setrlimit/setrlimit02
> /setrlimit/setrlimit03
> +/setrlimit/setrlimit04
> /setsid/setsid01
> /setsockopt/setsockopt01
> /settimeofday/settimeofday01
> diff --git a/testcases/kernel/syscalls/setrlimit/setrlimit04.c b/testcases/kernel/syscalls/setrlimit/setrlimit04.c
> new file mode 100644
> index 000000000000..13d1b9f98700
> --- /dev/null
> +++ b/testcases/kernel/syscalls/setrlimit/setrlimit04.c
> @@ -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));
> + } 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,
seems we need to filter out the suitable kernel:
.min_kver = "4.12.0",
--
Regards,
Li Wang
Email: liwang@redhat.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-17 5:01 ` Li Wang
@ 2017-07-17 6:50 ` Jan Stancek
2017-07-17 7:50 ` Li Wang
0 siblings, 1 reply; 9+ messages in thread
From: Jan Stancek @ 2017-07-17 6:50 UTC (permalink / raw)
To: ltp
----- Original Message -----
> On Fri, Jul 14, 2017 at 7:12 PM, Jan Stancek <jstancek@redhat.com> wrote:
> > 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.
...
> > +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",
Why, shouldn't this work on any kernel version?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-14 12:45 ` Richard Palethorpe
@ 2017-07-17 7:01 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2017-07-17 7:01 UTC (permalink / raw)
To: ltp
----- Original Message -----
>
> Hi Jan,
>
> Jan Stancek writes:
>
> > + * 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.
Yes. I didn't dig into details, but I think your formula below
is close.
> 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-17 6:50 ` Jan Stancek
@ 2017-07-17 7:50 ` Li Wang
2017-07-17 9:43 ` Jan Stancek
0 siblings, 1 reply; 9+ messages in thread
From: Li Wang @ 2017-07-17 7:50 UTC (permalink / raw)
To: ltp
On Mon, Jul 17, 2017 at 2:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> On Fri, Jul 14, 2017 at 7:12 PM, Jan Stancek <jstancek@redhat.com> wrote:
>> > 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.
> ...
>> > +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",
>
> 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?
--
Li Wang
liwang@redhat.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-17 7:50 ` Li Wang
@ 2017-07-17 9:43 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2017-07-17 9:43 UTC (permalink / raw)
To: ltp
----- Original Message -----
> On Mon, Jul 17, 2017 at 2:50 PM, Jan Stancek <jstancek@redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> On Fri, Jul 14, 2017 at 7:12 PM, Jan Stancek <jstancek@redhat.com> wrote:
> >> > 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.
> > ...
> >> > +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",
> >
> > 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?
Yes.
On side note, I also want a testcase in LTP where we on purpose keep
expanding stack until it hits existing mapping.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-07-14 11:12 [LTP] [PATCH] syscalls/setrlimit: add setrlimit04 Jan Stancek
2017-07-14 12:45 ` Richard Palethorpe
2017-07-17 5:01 ` Li Wang
@ 2017-10-02 13:11 ` Cyril Hrubis
2017-10-02 13:55 ` Jan Stancek
2 siblings, 1 reply; 9+ messages in thread
From: Cyril Hrubis @ 2017-10-02 13:11 UTC (permalink / raw)
To: ltp
Hi!
Looks good to me, acked.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 9+ messages in thread
* [LTP] [PATCH] syscalls/setrlimit: add setrlimit04
2017-10-02 13:11 ` Cyril Hrubis
@ 2017-10-02 13:55 ` Jan Stancek
0 siblings, 0 replies; 9+ messages in thread
From: Jan Stancek @ 2017-10-02 13:55 UTC (permalink / raw)
To: ltp
----- Original Message -----
> Hi!
> Looks good to me, acked.
I reworded first sentence (suggested by Richard) and pushed.
Regards,
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-10-02 13:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-14 11:12 [LTP] [PATCH] syscalls/setrlimit: add setrlimit04 Jan Stancek
2017-07-14 12:45 ` Richard Palethorpe
2017-07-17 7:01 ` Jan Stancek
2017-07-17 5:01 ` Li Wang
2017-07-17 6:50 ` Jan Stancek
2017-07-17 7:50 ` Li Wang
2017-07-17 9:43 ` Jan Stancek
2017-10-02 13:11 ` Cyril Hrubis
2017-10-02 13:55 ` Jan Stancek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox