syscalls/shmat01: avoid dumping corefile for expected crash
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
--- testcases/kernel/syscalls/ipc/shmat/shmat01.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
testcases/kernel/syscalls/ipc/shmat/shmat01.c +10 -2
@@ -69,8 +69,16 @@ static void *expected_addr(void *in_addr, void *out_addr)return ALIGN_DOWN (in_addr); } -static void do_child (int *in_addr) +static void do_child (int *in_addr,int expect_crash) { +if (expect_crash) { +/* crash is expected, avoid dumping corefile */ +struct rlimit r; + + r.rlim_cur =1 ; + r.rlim_max =1 ; +SAFE_SETRLIMIT (RLIMIT_CORE , &r); + } *in_addr =10 ;exit (0 );
@@ -121,7 +129,7 @@ static void verify_shmat(unsigned int n) pid =SAFE_FORK ();if (!pid) -do_child (addr); +do_child (addr, tc->exp_status ==SIGSEGV );else SAFE_WAITPID (pid, &status,0 );
Signature · 1 line
1.8.3.1
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
Hi!
I guess that this is optimization that speeds up the test, right?
testcases/kernel/syscalls/ipc/shmat/shmat01.c static void *expected_addr(void *in_addr, void *out_addr) · line 80
Quoted 10 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c +8
-1-static void do_child (int *in_addr) +static void do_child (int *in_addr,int expect_crash) { +if (expect_crash) { +/* crash is expected, avoid dumping corefile */ +struct rlimit r; + + r.rlim_cur =1 ; + r.rlim_max =1 ; +SAFE_SETRLIMIT (RLIMIT_CORE , &r);
Hmm, why not 0?
The manual says that when we set it to 0 no core file are created. I find that better than setting it to 1 which supposedly creates 1 byte file...
Signature · 2 lines
Cyril Hrubis [email protected]
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
----- Original Message -----
Quoted 2 lines
Hi!
I guess that this is optimization that speeds up the test, right?
That as well, but main reason is our automation, which scans for "unexpected corefiles". There is a blacklist, however this testcase mixes crashing/non-crashing inputs, so I wanted to avoid any corefiles and keep it off blacklist.
Quoted 13 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c static void *expected_addr(void *in_addr, void *out_addr) · line 80
Quoted 11 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c +8
-1-static void do_child (int *in_addr) +static void do_child (int *in_addr,int expect_crash) { +if (expect_crash) { +/* crash is expected, avoid dumping corefile */ +struct rlimit r; + + r.rlim_cur =1 ; + r.rlim_max =1 ; +SAFE_SETRLIMIT (RLIMIT_CORE , &r);Hmm, why not 0?
1 is a special case, that disables also coredump-into-pipe, and it also happens to be small enough to skip coredump-to-file.
fs/coredump.c:
"if (cprm.limit == 1) {"
Quoted 4 lines
The manual says that when we set it to 0 no core file are created. I find that better than setting it to 1 which supposedly creates 1 byte file...
That shouldn't happen because of this check:
if (cprm.limit < binfmt->min_coredump)
Regards,
Jan
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
Hi!
Quoted 19 lines
Quoted 4 lines
Quoted 4 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c +2
-1-static void do_child (int *in_addr) +static void do_child (int *in_addr,int expect_crash) { +if (expect_crash) {Quoted 8 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c static void *expected_addr(void *in_addr, void *out_addr) · line 80
Quoted 6 lines
testcases/kernel/syscalls/ipc/shmat/shmat01.c +6
-0+/* crash is expected, avoid dumping corefile */ +struct rlimit r; + + r.rlim_cur =1 ; + r.rlim_max =1 ; +SAFE_SETRLIMIT (RLIMIT_CORE , &r);Hmm, why not 0?
1 is a special case, that disables also coredump-into-pipe, and it also happens to be small enough to skip coredump-to-file.
fs/coredump.c:
"if (cprm.limit == 1) {"
Quoted 6 lines
Quoted 3 lines
The manual says that when we set it to 0 no core file are created. I find that better than setting it to 1 which supposedly creates 1 byte file...
That shouldn't happen because of this check:
if (cprm.limit <binfmt->min_coredump)
I guess that we should get the setrlimit manual page update then.
Looking at the kernel code it will skip the core-file creation silently unless the minimal size > PAGE_SIZE for most of the binfmt handlers.
Signature · 2 lines
Cyril Hrubis [email protected]
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
Hi!
Quoted 10 lines
Quoted 10 lines
1 is a special case, that disables also coredump-into-pipe, and it also happens to be small enough to skip coredump-to-file.
fs/coredump.c:
"if (cprm.limit == 1) {"Quoted 3 lines
The manual says that when we set it to 0 no core file are created. I find that better than setting it to 1 which supposedly creates 1 byte file...
Quoted 7 lines
Quoted 2 lines
That shouldn't happen because of this check:
if (cprm.limit <binfmt->min_coredump)I guess that we should get the setrlimit manual page update then.
Looking at the kernel code it will skip the core-file creation silently unless the minimal size >
PAGE_SIZEfor most of the binfmt handlers.
Also consider the patch acked, but please add a bit more descriptive commit message, i.e. why the limit is set to 1 and not 0.
Signature · 2 lines
Cyril Hrubis [email protected]
PATCH 1/1 syscalls/shmat01: avoid dumping corefile for expected crash
----- Original Message -----
Quoted 14 lines
Hi!
Quoted 13 lines
Quoted 12 lines
1 is a special case, that disables also coredump-into-pipe, and it also happens to be small enough to skip coredump-to-file.
fs/coredump.c:
"if (cprm.limit == 1) {"Quoted 3 lines
The manual says that when we set it to 0 no core file are created. I find that better than setting it to 1 which supposedly creates 1 byte file...
That shouldn't happen because of this check:
if (cprm.limit <binfmt->min_coredump)
Quoted 7 lines
Quoted 4 lines
I guess that we should get the setrlimit manual page update then.
Looking at the kernel code it will skip the core-file creation silently unless the minimal size >
PAGE_SIZEfor most of the binfmt handlers.Also consider the patch acked, but please add a bit more descriptive commit message, i.e. why the limit is set to 1 and not 0.
Pushed with extra comment.
Regards,
Jan