public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Scott James Remnant <scott@ubuntu.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	earl_chew@agilent.com
Subject: Re: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern
Date: Sat, 1 Aug 2009 09:41:46 -0400	[thread overview]
Message-ID: <20090801134146.GA19910@localhost.localdomain> (raw)
In-Reply-To: <1249071610.4800.5.camel@wing-commander>

On Fri, Jul 31, 2009 at 09:20:10PM +0100, Scott James Remnant wrote:
> On Wed, 2009-07-29 at 16:18 -0400, Neil Horman wrote:
> 
> > On Wed, Jul 29, 2009 at 04:13:02PM +0100, Scott James Remnant wrote:
> > > On Mon, 2009-06-22 at 13:28 -0400, Neil Horman wrote:
> > > 
> > > > 2) Allow for the kernel to wait for a core_pattern process to complete.  One of
> > > > the things core_pattern processes might do is interrogate the status of a
> > > > crashing process via its /proc/pid directory.  To ensure that that directory is
> > > > not removed prematurely, we wait for the process to exit prior to cleaning it
> > > > up.
> > > > 
> > > Would this mean that the kernel would wait for the pattern process to
> > > complete before PANIC in the case of init core dumping?
> > > 
> > > I'd find that useful :-)
> > > 
> > Not without additional work.  If init crashed in the initramfs, I don't think
> > theres a way to handle that.  If it crashes at some later time, I think it just
> > gets restarted IIRC.  I'm sure you can change that behavior, but this patch
> > doesn't address that.
> > 
> When the system init daemon crashes, the kernel PANICs.  When not using
> core_pattern, this is ok, we get a core file - when using apport, as far
> as I can tell it never waits for apport to finish so we don't get the
> crash.
> 
This is non-sensical.  If init crashes, and the kernel panics, you'll only get a
core by sheer luck and good fortune.  The kernels paniced, theres no
serialization between the halting/rebooting of cpus and the completion of a core
dump operation, be it to a pipe or disk.

> I was hoping that by waiting for the core_pattern process to finish,
> this might solve this issue.
> 
See above, some of it might work, but if the kernel is going to panic, theres no
way to fork another process, let alone wait for it to finish, at least not with
any level of reliability.

> The other obvious fix I can apply to the init daemon is to reset the
> core pattern and deliberately dump core somewhere that can be picked up.
> 
how are you getting this core if the system is actually panic'ed?  Or is
something else actually happening.

> > If you want to debug a custom init process, why not run a wrapper program as
> > init, that just forks the init you want to run and captures the core when it
> > crashes?
> > 
> Because then that's not the init daemon; it's not pid 1, it doesn't have
> processes reparented to it.  And it's very annoying having the entire
> system reparented to gdb, which doesn't deal so well with that ;-)
> 

You're not by any chance talking about an init crash that results in a respawn
are you?  That doesn't result in a panic, and would allow for a crash to
complete.  If thats the case, then core_pattern might just work (I admit to not
having tried it).

Neil

> Scott
> -- 
> Scott James Remnant
> scott@ubuntu.com



  reply	other threads:[~2009-08-01 13:41 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-22 17:28 [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern Neil Horman
2009-06-25 23:30 ` Andrew Morton
2009-06-26  1:49   ` Neil Horman
2009-06-26 10:48   ` Neil Horman
2009-06-26 16:20     ` Andrew Morton
2009-06-26 17:30       ` Neil Horman
2009-06-28 19:31       ` Andi Kleen
2009-06-28 20:52         ` Andrew Morton
2009-06-28 21:00           ` Andi Kleen
2009-06-28 21:18             ` Andrew Morton
2009-06-28 21:50               ` Eric W. Biederman
2009-06-28 21:35           ` Eric W. Biederman
2009-06-28 21:48             ` Andi Kleen
2009-06-28 22:06               ` Eric W. Biederman
2009-06-29  9:15                 ` Andi Kleen
2009-06-28 21:52             ` Andrew Morton
2009-06-26 18:00   ` Neil Horman
2009-06-26 18:02   ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: recursive dump detection Neil Horman
2009-06-26 16:59     ` Oleg Nesterov
2009-06-26 20:24       ` Neil Horman
2009-06-26 19:14         ` [PATCH 0/2] do_coredump: misc cleanups Oleg Nesterov
2009-06-26 19:14           ` [PATCH 1/2] do_coredump: factor out put_cred() calls Oleg Nesterov
2009-06-26 22:40             ` Roland McGrath
2009-06-26 20:33               ` Oleg Nesterov
2009-06-26 19:16           ` [PATCH 2/2] do_coredump: move !ispipe code into "else" branch Oleg Nesterov
2009-06-26 20:18             ` Q: do_coredump() && d_unhashed() Oleg Nesterov
2009-06-26 22:57           ` [PATCH 0/2] do_coredump: misc cleanups Neil Horman
2009-06-26 19:37     ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: recursive dump detection Andrew Morton
2009-06-26 20:17       ` Neil Horman
2009-06-26 18:03   ` [PATCH 2/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern: wait for core collectors Neil Horman
2009-06-26 16:48     ` Oleg Nesterov
2009-06-26 20:20       ` Neil Horman
2009-06-29  0:33   ` [PATCH 1/2] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v3) Neil Horman
2009-06-29  0:35   ` [PATCH 2/2] " Neil Horman
2009-06-28 22:24     ` Oleg Nesterov
2009-06-28 23:24       ` Oleg Nesterov
2009-06-29  2:36       ` Neil Horman
2009-06-28 23:32         ` Oleg Nesterov
2009-06-29 10:21           ` Neil Horman
2009-06-30  0:06             ` Oleg Nesterov
2009-06-29  0:32 ` [PATCH 0/2] " Neil Horman
2009-06-30 17:38 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v4) Neil Horman
2009-06-30 17:42   ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v4) Neil Horman
2009-06-30 17:43   ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v4) Neil Horman
2009-06-30 17:46   ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v4) Neil Horman
2009-07-01  5:52     ` Oleg Nesterov
2009-07-01 10:31       ` Neil Horman
2009-07-01 12:25         ` Oleg Nesterov
2009-07-01 14:12           ` Neil Horman
2009-07-01 14:48             ` Oleg Nesterov
2009-07-01 15:26 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v5) Neil Horman
2009-07-01 15:30   ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v5) Neil Horman
2009-07-01 15:34   ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v5) Neil Horman
2009-07-01 15:37   ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v5) Neil Horman
2009-07-01 16:06     ` Oleg Nesterov
2009-07-01 18:19       ` Neil Horman
2009-07-01 18:28 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v6) Neil Horman
2009-07-01 18:31   ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v6) Neil Horman
2009-07-01 18:32   ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v6) Neil Horman
2009-07-01 18:37   ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v6) Neil Horman
2009-07-02  8:29     ` Oleg Nesterov
2009-07-02 10:29       ` Neil Horman
2009-07-02 11:36         ` Oleg Nesterov
2009-07-02 14:44           ` Neil Horman
2009-07-02 15:37             ` Oleg Nesterov
2009-07-02 17:53               ` Neil Horman
2009-07-03 10:10                 ` Oleg Nesterov
2009-07-02 22:57 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v7) Neil Horman
2009-07-02 22:59   ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v7) Neil Horman
2009-07-02 23:00   ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v7) Neil Horman
2009-07-02 23:01   ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v7) Neil Horman
2009-07-03 10:16     ` Oleg Nesterov
2009-07-03 10:44 ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v8) Neil Horman
2009-07-03 10:50   ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v8) Neil Horman
2009-07-07 16:14     ` Neil Horman
2009-07-03 10:51   ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v8) Neil Horman
2009-07-07 16:15     ` Neil Horman
2009-07-03 10:52   ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v8) Neil Horman
2009-07-07 16:19     ` Neil Horman
2009-07-07 16:35       ` Oleg Nesterov
2009-07-07 16:13   ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v8) Neil Horman
2009-07-20 15:49   ` [PATCH 0/3] exec: Make do_coredump more robust and safer when using pipes in core_pattern (v9) Neil Horman
2009-07-20 16:27     ` [PATCH 1/3] exec: Make do_coredump more resilient to recursive crashes (v9) Neil Horman
2009-07-20 16:29     ` [PATCH 2/3] exec: let do_coredump limit the number of concurrent dumps to pipes (v9) Neil Horman
2009-08-07 17:08       ` Randy Dunlap
2009-07-20 16:32     ` [PATCH 3/3] exec: Allow do_coredump to wait for user space pipe readers to complete (v9) Neil Horman
2009-07-29 15:13 ` [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern Scott James Remnant
2009-07-29 20:18   ` Neil Horman
2009-07-31 20:20     ` Scott James Remnant
2009-08-01 13:41       ` Neil Horman [this message]
2009-08-01 18:28         ` Scott James Remnant
2009-08-02  0:22           ` Neil Horman
2009-08-02 13:49             ` Scott James Remnant
2009-08-02 23:50               ` Neil Horman

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=20090801134146.GA19910@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=akpm@linux-foundation.org \
    --cc=earl_chew@agilent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott@ubuntu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox