|| ||"Suzuki K. Poulose" <firstname.lastname@example.org> |
|| ||email@example.com |
|| ||[RFC] [Patch 0/21] Non disruptive application core dump
|| ||Tue, 14 Dec 2010 15:22:59 +0530|
|| ||Jeremy Fitzhardinge <firstname.lastname@example.org>,
Christoph Hellwig <email@example.com>,
Masami Hiramatsu <firstname.lastname@example.org>,
Ananth N Mavinakayanahalli <email@example.com>,
Daisuke HATAYAMA <firstname.lastname@example.org>,
Andi Kleen <email@example.com>,
Roland McGrath <firstname.lastname@example.org>,
Amerigo Wang <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
KAMEZAWA Hiroyuki <email@example.com>,
KOSAKI Motohiro <firstname.lastname@example.org>,
Oleg Nesterov <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
"Suzuki K. Poulose" <email@example.com>|
|| ||Article, Thread
This is series of patches implementing an infrastructure for capturing the core
of an application without disrupting its process semantics.
The infrastructure makes use of the freezer subsystem in kernel to freeze the
threads and then collect the information to generate the core.
The interface is provided by a /proc/pid/core file, reading which can give the
ELF formatted core of the process with "pid". The interface supports "seek"
operation on the fd, allowing the dumper to have control on the data that is
being dumped. Also it allows the user to store the dump at any location.
The current implementation supports both native as well as the compat ELF
An open() call to the /proc/pid/core will try to freeze the threads in the
process and the read() requests will dynamically generate the contents for the
core file. The ELF header & Program Headers are stored in a kernel buffer to
allow us to map the fpos to the required data section.
In case a thread is not frozen within a time interval, after issuing the freeze
request, we fill the register state information with 0's to indicate we could
not capture the data.
A close() would kick the threads out of the refrigerator().
The implementation reuses some of the existing ELF core generation code by
exporting them. Some of the code common to both native and compat ELF class
support has been moved to a common place, elfcore-common.c. Also some of the
reusable functions, specific to the ELF class handling, has been made global,
after renaming the compat version of the same.
We also added a new API -elf_core_copy_extra_phdrs() -for "reading" the arch
specific program headers, versus the existing elf_core_write_extra_phdrs().
Patches 1 to 9 deals with re-arranging the ELF code to be reusable by the
Patches 10 to 21 implements the infrastructure.
TODO: Add support for collecting the arch specific notes, currently used only
by Cell platform.
Please let me know your review comments / thoughts.
arch/ia64/kernel/elfcore.c | 34 ++
arch/um/sys-i386/elfcore.c | 32 ++
fs/Makefile | 1
fs/binfmt_elf.c | 162 +------------
fs/compat_binfmt_elf.c | 7
fs/elfcore-common.c | 138 +++++++++++
fs/proc/Makefile | 2
fs/proc/base.c | 1
fs/proc/gencore-compat-elf.c | 61 ++++
fs/proc/gencore-elf.c | 479+++++++++++++++++++++++++++++++++++++++
fs/proc/gencore.c | 297++++++++++++++++++++++++
fs/proc/gencore.h | 71 +++++
fs/proc/internal.h | 1
include/linux/elfcore-internal.h | 73 +++++
include/linux/elfcore.h | 3
include/linux/freezer.h | 12
kernel/elfcore.c | 6
kernel/power/process.c | 9
18 files changed, 1241 insertions(+), 148 deletions(-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/