LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Markus Gutschke <firstname.lastname@example.org> To: "Kawai, Hidehiro" <email@example.com> Cc: Andrew Morton <firstname.lastname@example.org>, kernel list <email@example.com>, Pavel Machek <firstname.lastname@example.org>, Robin Holt <email@example.com>, firstname.lastname@example.org, Alan Cox <email@example.com>, Masami Hiramatsu <firstname.lastname@example.org>, sugita <email@example.com>, Satoshi OSHIMA <firstname.lastname@example.org>, "Hideo AOKI@redhat" <email@example.com> Subject: Re: [PATCH 0/4] coredump: core dump masking support v3 Date: Thu, 01 Mar 2007 10:16:21 -0800 [thread overview] Message-ID: <45E71875.firstname.lastname@example.org> (raw) In-Reply-To: <45E6C888.email@example.com> Kawai, Hidehiro wrote: > Requirements are: > (1) a user can change the core dump settings _anytime_ > - sometimes want to dump anonymous shared memory segments and > sometimes don't want to dump them I might not have been sufficiently clear about this in my previous e-mail. Currently, the Google coredumper does not have the feature that you asked about, but adding it would be trivial -- it just hadn't been needed, yet, as on-the-fly compression was good enough for most users. Answering your question, I don't see any reason why the new API would not be able to make changes at any time. > (2) a user can change the core dump settings of _any processes_ > (although permission checks are performed) > - in a huge application which forks many processes, a user > hopes that some processes dump anonymous shared memory > segments and some processes don't dump them The Google coredumper is a library that needs to be linked into the application and needs to be called from appropriate signal handlers. As such, it is the application's responsibility what management API it wants to expose externally, and what tools it wants to provide for managing a group of processes. > And reliability of the core dump feature is also important. We have generally had very good reliability with the Google coredumper. In some cases, it even works a little more reliably than the default in-kernel dumper (e.g. because we can control where to write the file, and whether it should be compressed on-the-fly; or because we can get multi-threaded coredumps even in situations where the particular combination of libc and kernel doesn't support this), and in other cases the in-kernel dumper works a little better (e.g. if an application got too corrupted to even run any signal handlers). Realistically, it just works. But we did have to make sure that we set up alternate stacks for signal processing, and that we made sure that these stacks have been dirtied in order to avoid problems with memory overcomitting. > And all the software vendors don't necessarily apply > google-coredumper. If the vendor doesn't apply it, the user will > be bothered by huge core dumps or the buggy application which > remains unfixed. So I believe that in kernel solution is still > needed. I agree that the Google coredumper is only one possible solution to your problem. Depending on how your production environment looks like, it might help a lot, or it might be completely useless. If it is cheap for you to modify your applications, but expensive to upgrade your kernels, the Google coredumper is the way to go. Also, if you need the extra features, such as the ability to compress core files on-the-fly, or the ability to send corefiles to somewhere other than an on-disk file, you definitely should look at a user-space solution. On the other hand, if you can easily upgrade all your kernels, but you don't even have access to the source of your applications, then an in-kernel solution is much better. Markus
next prev parent reply other threads:[~2007-03-01 18:17 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-16 13:34 [PATCH 0/4] coredump: core dump masking support v3 Kawai, Hidehiro 2007-02-16 13:39 ` [PATCH 1/4] coredump: add an interface to control the core dump routine Kawai, Hidehiro 2007-02-16 13:40 ` [PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory Kawai, Hidehiro 2007-02-16 13:41 ` [PATCH 3/4] coredump: ELF-FDPIC: " Kawai, Hidehiro 2007-02-16 13:42 ` [PATCH 4/4] coredump: documentation for proc entry Kawai, Hidehiro 2007-02-16 15:05 ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory David Howells 2007-02-16 16:50 ` Robin Holt 2007-02-16 20:09 ` David Howells 2007-03-02 16:55 ` Hugh Dickins 2007-03-03 14:10 ` David Howells 2007-03-05 19:04 ` Hugh Dickins 2007-03-06 18:13 ` David Howells 2007-03-09 14:12 ` Move to unshared VMAs in NOMMU mode? David Howells 2007-03-12 20:50 ` Robin Getz 2007-03-13 10:14 ` David Howells 2007-03-15 21:20 ` Hugh Dickins 2007-03-15 22:47 ` David Howells 2007-03-19 19:23 ` Eric W. Biederman 2007-03-20 11:06 ` David Howells 2007-03-20 16:48 ` Eric W. Biederman 2007-03-20 19:12 ` David Howells 2007-03-20 19:51 ` David Howells 2007-03-21 16:11 ` David Howells 2007-03-03 14:25 ` [PATCH] NOMMU: Hide vm_mm in NOMMU mode David Howells 2007-02-20 9:45 ` [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory Kawai, Hidehiro 2007-02-20 10:58 ` David Howells 2007-02-20 12:56 ` Robin Holt 2007-02-21 10:00 ` Kawai, Hidehiro 2007-02-21 11:33 ` David Howells 2007-02-21 11:54 ` Robin Holt 2007-02-22 5:33 ` Kawai, Hidehiro 2007-02-22 11:47 ` David Howells 2007-02-16 15:08 ` [PATCH 0/4] coredump: core dump masking support v3 David Howells 2007-02-20 9:48 ` Kawai, Hidehiro 2007-02-24 3:32 ` Markus Gutschke 2007-02-24 11:39 ` Pavel Machek 2007-03-01 12:35 ` Kawai, Hidehiro 2007-03-01 18:16 ` Markus Gutschke [this message] 2007-02-24 10:02 ` David Howells 2007-02-24 20:01 ` Markus Gutschke 2007-02-26 11:49 ` David Howells 2007-02-26 12:01 ` Pavel Machek 2007-02-26 12:42 ` David Howells
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=45E71875.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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: linkBe 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; as well as URLs for NNTP newsgroup(s).