All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: paul@mad-scientist.net, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing
Date: Wed, 27 May 2009 21:05:13 +0200	[thread overview]
Message-ID: <20090527190513.GA32452@redhat.com> (raw)
In-Reply-To: <20090527185056.GW1065@one.firstfloor.org>

On 05/27, Andi Kleen wrote:
>
> > Actually, I think there is a strong reason to handle signals during
> > core dumping. The coredump can take a lot of time/resources, not good
> > it looks like unkillable procees to users.
>
> One problem with that is if you send a process a string of signals that cause
> a core dump and then kill. In the old case you would just get a full core dump
> on the first signal and be done. With your change it would process
> the second signal too and stop the dumping and you get none or a partial
> core dump. That might well break existing setups.

I don't think we should worry about this particular case. Suppose a user
does

	kill(pid, SIGQUIT);
	kill(pid, SIGKILL);

In this case, most likely the core dump will not start. Because SIGKILL
will set SIGNAL_GROUP_EXIT before the process dequeues SIGQUIT and start
do_coredump() which checks signal_group_exit() in zap_threads().

But yes, I agree, this change is user-visible and should be discussed.

Oleg.


  reply	other threads:[~2009-05-27 19:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 16:33 [2.6.27.24] Kernel coredump to a pipe is failing Paul Smith
2009-05-26 18:01 ` Paul Smith
2009-05-26 20:31 ` Andi Kleen
2009-05-26 21:09   ` Paul Smith
2009-05-26 23:00   ` Andrew Morton
2009-05-26 23:14     ` Andi Kleen
2009-05-26 23:28       ` Andrew Morton
2009-05-26 23:41         ` Andi Kleen
2009-05-26 23:45           ` Andrew Morton
2009-05-27  0:11             ` Andi Kleen
2009-05-27  0:29               ` Andrew Morton
2009-05-27  6:02                 ` Paul Smith
2009-05-27  6:17                 ` Paul Smith
2009-05-27  7:31                 ` Andi Kleen
2009-05-27  7:45                   ` Andrew Morton
2009-05-27  8:52                     ` Andi Kleen
2009-05-27  8:56                       ` Andrew Morton
2009-05-27 20:25           ` Jesper Juhl
2009-05-29 10:34           ` Pavel Machek
2009-05-27 18:31   ` Oleg Nesterov
2009-05-27 18:50     ` Andi Kleen
2009-05-27 19:05       ` Oleg Nesterov [this message]
2009-05-27 19:49         ` Paul Smith
2009-05-27 20:34           ` Oleg Nesterov
2009-05-27 20:04     ` Oleg Nesterov
2009-05-27 20:22       ` Paul Smith
  -- strict thread matches above, loose matches on Subject: below --
2009-05-22 12:34 Paul Smith

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=20090527190513.GA32452@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@mad-scientist.net \
    --cc=roland@redhat.com \
    /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.