* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
@ 2017-09-11 11:32 Jan Stancek
2017-09-11 11:53 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2017-09-11 11:32 UTC (permalink / raw)
To: ltp
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
testcases/kernel/syscalls/ipc/shmat/shmat01.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/testcases/kernel/syscalls/ipc/shmat/shmat01.c b/testcases/kernel/syscalls/ipc/shmat/shmat01.c
index 0ea407530462..ad0410aac127 100644
--- a/testcases/kernel/syscalls/ipc/shmat/shmat01.c
+++ b/testcases/kernel/syscalls/ipc/shmat/shmat01.c
@@ -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);
--
1.8.3.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
2017-09-11 11:32 [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash Jan Stancek
@ 2017-09-11 11:53 ` Cyril Hrubis
2017-09-11 12:08 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2017-09-11 11:53 UTC (permalink / raw)
To: ltp
Hi!
I guess that this is optimization that speeds up the test, right?
> -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...
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
2017-09-11 11:53 ` Cyril Hrubis
@ 2017-09-11 12:08 ` Jan Stancek
2017-09-11 12:21 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2017-09-11 12:08 UTC (permalink / raw)
To: ltp
----- Original Message -----
> 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.
>
> > -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) {"
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
2017-09-11 12:08 ` Jan Stancek
@ 2017-09-11 12:21 ` Cyril Hrubis
2017-09-12 9:15 ` Cyril Hrubis
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2017-09-11 12:21 UTC (permalink / raw)
To: ltp
Hi!
> > > -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) {"
>
> > 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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
2017-09-11 12:21 ` Cyril Hrubis
@ 2017-09-12 9:15 ` Cyril Hrubis
2017-09-12 12:46 ` Jan Stancek
0 siblings, 1 reply; 6+ messages in thread
From: Cyril Hrubis @ 2017-09-12 9:15 UTC (permalink / raw)
To: ltp
Hi!
> > 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) {"
> >
> > > 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.
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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 6+ messages in thread* [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
2017-09-12 9:15 ` Cyril Hrubis
@ 2017-09-12 12:46 ` Jan Stancek
0 siblings, 0 replies; 6+ messages in thread
From: Jan Stancek @ 2017-09-12 12:46 UTC (permalink / raw)
To: ltp
----- Original Message -----
> Hi!
> > > 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) {"
> > >
> > > > 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.
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-09-12 12:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-11 11:32 [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash Jan Stancek
2017-09-11 11:53 ` Cyril Hrubis
2017-09-11 12:08 ` Jan Stancek
2017-09-11 12:21 ` Cyril Hrubis
2017-09-12 9:15 ` Cyril Hrubis
2017-09-12 12:46 ` Jan Stancek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox