All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/shmat01: avoid dumping corefile for expected crash
Date: Mon, 11 Sep 2017 14:21:14 +0200	[thread overview]
Message-ID: <20170911122114.GB22586@rei.lan> (raw)
In-Reply-To: <154541893.12328039.1505131686278.JavaMail.zimbra@redhat.com>

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

  reply	other threads:[~2017-09-11 12:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-09-12  9:15       ` Cyril Hrubis
2017-09-12 12:46         ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170911122114.GB22586@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.