Message-ID: <20140320093040.14878.903.stgit@localhost.localdomain>
Date:	Thu, 20 Mar 2014 15:09:03 +0530
From:	Janani Venkataraman <jananive@...ux.vnet.ibm.com>
To:	linux-kernel@...r.kernel.org
Cc:	amwang@...hat.com, procps@...elists.org, rdunlap@...otime.net,
	james.hogan@...tec.com, aravinda@...ux.vnet.ibm.com, hch@....de,
	mhiramat@...hat.com, jeremy.fitzhardinge@...rix.com,
	xemul@...allels.com, d.hatayama@...fujitsu.com, coreutils@....org,
	kosaki.motohiro@...fujitsu.com, adobriyan@...il.com,
	util-linux@...r.kernel.org, tarundsk@...ux.vnet.ibm.com,
	vapier@...too.org, roland@...k.frob.com, ananth@...ux.vnet.ibm.com,
	gorcunov@...nvz.org, avagin@...nvz.org, oleg@...hat.com,
	eparis@...hat.com, suzuki@...ux.vnet.ibm.com, andi@...stfloor.org,
	tj@...nel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: [PATCH 00/33] [RFC] Non disruptive application core dump
 infrastructure

Hi all,

The following series implements an infrastructure for capturing the core of an
application without disrupting its process.

Kernel Space Approach:

1) Posted an RFD to LKML explaining the various kernel-methods being analysed.

https://lkml.org/lkml/2013/9/3/122

2) Went ahead to implement the same using the task_work_add approach and posted an
RFC to LKML.

http://lwn.net/Articles/569534/

Based on the responses, the present approach implements the same in User-Space.

User Space Approach:

We didn't adopt the CRIU approach because our method would give us a head
start, as all that the distro would need is the PTRACE_functionality and nothing
more which is available from kernel versions 3.4 and above.

Basic Idea of User Space:

1) The threads are held using PTRACE_SEIZE and PTRACE_INTERRUPT.

2) The dump is then taken using the following:
    1) The register sets namely general purpose, floating point and the arch
    specific register sets are collected through PTRACE_GETREGSET calls by
    passing the appropriate register type as parameter.
    2) The virtual memory maps are collected from /proc/pid/maps.
    3) The auxiliary vector is collected from /proc/pid/auxv.
    4) Process state information for filling the notes such as PRSTATUS and
    PRPSINFO are collected from /proc/pid/stat and /proc/pid/status.
    5) The actual memory is read through process_vm_readv syscall as suggested
    by Andi Kleen.
    6) Command line arguments are collected from /proc/pid/cmdline

3) The threads are then released using PTRACE_DETACH.

Self Dump:

A self dump is implemented with the following approach which was adapted
from CRIU:

Gencore Daemon

The programs can request a dump using gencore() API, provided through
libgencore. This is implemented through a daemon which listens on a UNIX File
socket. The daemon is started immediately post installation.

We have provided service scripts for integration with systemd.

NOTE:

On systems with systemd, we could make use of socket option, which will avoid
the need for running the gencore daemon always. The systemd can wait on the
socket for requests and trigger the daemon as and when required. However, since
the systemd socket APIs are not exported yet, we have disabled the supporting
code for this feature.

libgencore:

1) The client interface is a standard library call. All that the dump requester
does is open the library and call the gencore() API and the dump will be
generated in the path specified(relative/absolute).

To Do:

1) Presently we wait indefinitely for the all the threads to seize. We can add
a time-out to decide how much time we need to wait for the threads to be
seized. This can be passed as command line argument in the case of a third
party dump and in the case of the self-dump through the library call. We need
to work on how much time to wait.

2) Like mentioned before, the systemd socket APIs are not exported yet and
hence this option is disabled now. Once these API's are available we can enable
the socket option.

We would like to push this to one of the following packages:
a) util-linux
b) coreutils
c) procps-ng

We are not sure which one would suit this application the best.
Please let us know your views on the same.

Patches 1 - 16 implements the dump generation.

Patches 17 - 24 implements the daemon approach.

Patch 25 implements the systemd socket approach.

Patches 26-27 implements the client-interface library.

Patches 28-33 handles the building and other packaging aspects.

Please let us know your reviews and comments.

Thanks.

Janani Venkataraman (33):
      Configure and Make files
      Validity of arguments
      Process Status
      Hold threads
      Fetching Memory maps
      Check ELF class
      Do elf_coredump
      Fills elf header
      Adding notes infrastructure
      Populates PRPS info
      Populate AUXV
      Fetch File maps
      Fetching thread specific Notes
      Populating Program Headers
      Updating Offset
      Writing to core file
      Daemonizing the Process
      Socket operations
      Block till request
      Handling Requests
      Get Clients PID
      Dump the task
      Handling SIG TERM of the daemon
      Handling SIG TERM of the child
      Systemd Socket ID retrieval
      [libgencore] Setting up Connection
      [libgencore] Request for dump
      Man pages
      Automake files for the doc folder
      README, COPYING, Changelog
      Spec file
      Socket and Service files.
      Support check


 COPYING            |   24 ++
 COPYING.LIBGENCORE |   24 ++
 Changelog          |    7 
 Makefile.am        |   22 +
 README             |  108 +++++++
 configure.ac       |    8 +
 doc/Makefile.am    |    2 
 doc/gencore.1      |   31 ++
 doc/gencore.3      |   28 ++
 gencore.service    |    9 +
 gencore.socket     |   10 +
 gencore.spec.in    |   88 ++++++
 gencore@...rvice   |    9 +
 libgencore.pc.in   |    8 +
 src/Makefile.am    |   13 +
 src/client.c       |  121 ++++++++
 src/coredump.c     |  764 ++++++++++++++++++++++++++++++++++++++++++++++++
 src/coredump.h     |   74 +++++
 src/elf-compat.h   |  124 ++++++++
 src/elf.c          |  827 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/elf32.c        |   43 +++
 src/elf64.c        |   44 +++
 src/gencore.h      |    1 
 src/proc.c         |  278 +++++++++++++++++
 24 files changed, 2667 insertions(+)
 create mode 100644 COPYING
 create mode 100644 COPYING.LIBGENCORE
 create mode 100644 Changelog
 create mode 100644 README
 create mode 100644 doc/Makefile.am
 create mode 100644 doc/gencore.1
 create mode 100644 doc/gencore.3
 create mode 100644 gencore.service
 create mode 100644 gencore.socket
 create mode 100644 gencore.spec.in
 create mode 100644 gencore@...rvice
 create mode 100644 libgencore.pc.in
 create mode 100644 src/Makefile.am
 create mode 100644 src/client.c
 create mode 100644 src/coredump.c
 create mode 100644 src/coredump.h
 create mode 100644 src/elf-compat.h
 create mode 100644 src/elf.c
 create mode 100644 src/elf32.c
 create mode 100644 src/elf64.c
 create mode 100644 src/gencore.h
 create mode 100644 src/proc.c

-- 
Janani

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists