lkml.org 
[lkml]   [2013]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRFD: Non-Disruptive Core Dump Infrastructure
    Hello,

    We are working on an infrastructure to create a system core file of a specific
    process at run-time, non-disruptively. It can also be extended to a case where
    a process is able to take a self-core dump.

    gcore, an existing utility creates a core image of the specified process. It
    attaches to the process using gdb and runs the gdb gcore command and then
    detaches. In gcore the dump cannot be issued from a signal handler context as
    fork() is not signal safe and moreover it is disruptive in nature as the gdb
    attaches using ptrace which sends a SIGSTOP signal. Hence the gcore method
    cannot be used if the process wants to initiate a self dump.

    Previously the non-disruptive dump was tried with the Utrace approach [1].
    First, all the threads would be assembled at a common place and quiesced using
    UTRACE_INTERRUPT. Then the core dump would be triggered upon receiving the
    event, indicating that the last thread of the process has quiesced, from its
    quiesce callback. After several reviews and discussions, the Linux community
    decided not to accept this proposal and has not pushed it upstream due to
    various dependencies and potential risk of breaking existing implementations.
    Hence the UTRACE approach is not being pursued. Also Roland had mentioned that
    even if the approach worked smoothly,the pause could be a significant
    perturbation [2].

    Another approach was using the Freezer subsystem[3]. The freezer functions in
    kernel essentially help start and stop sets of tasks and this approach
    exploited the existing freezer subsystem kernel interface effectively to
    quiesce all the threads of the application before triggering the core dump.
    This approach was not accepted due to the potential Dos attack. Also the
    community discussed that "freeze" is a bit dangerous because an application
    which is frozen cannot be ended and while it's frozen and there is no
    information "its frozen" via usual user commands as 'ps' or 'top'.

    So ideally what we are trying to do is to export the infrastructure using
    /proc/pid/core. Reading the file would give an ELF Format core-dump at that
    instant non-disruptively,without killing the process.

    This would involve basically three operations:

    1) Holding the threads of a process without sending a signal (SIGSTOP). At this
    point we can collect the register set snapshot and collect other information
    required to create the ELF header. The above operation could be initiated with
    the open() call.
    2) Once the ELF header is created, read() can return the CORE DUMP data
    including, the process memory page-by-page, based on the fpos (file position).
    3) The threads could be released upon a close().

    So the sub-problem here would be "How to hold these threads,collect the data
    and release them non-disruptively?" in order to take a consistent dump.

    As Roland had mentioned we could have a user option of having a minimal dump or
    a full dump. The minimal dump can get a full register snapshot of the threads
    running in user mode, and as much information as possible for those threads
    that are blocked. Wheres a full dump can additionally get a memory dump as well.

    If we provide the user a way to abort the operation, say keeping the threads in
    an interruptible state, we should be able to prevent the doS attack which was
    present in the method using the Freezer subsystem. For example we can send a
    signal to the process and it should abort the dump operation and release the
    threads.

    We have analyzed the following options and we would like to know what people
    think is the best or if there are any other mechanisms to perform the operation,
    we would be happy to look at it.

    1) Task work add

    task_work_add() is an interface and an API. The task work add will run any
    queued work before returning to user space from the kernel. So that work is
    guaranteed to be done before user space can run again.

    * Exploit this function to hold the threads when they are returning to the
    user space.
    * Wait until all the threads of the process to be dumped, reach task_work_add.
    * Once all the threads have reached, the dump is taken and they are released.

    Disadvantage :
    * A thread which is blocked in kernel space,would not return to user space soon
    and hence wouldn't be trapped in the task_work_add function
    * The dump may be delayed as the other threads would be waiting for this
    specific blocked thread to reach.

    Solution:
    * A way to solve this problem is to make the other threads that are waiting,
    wait for a fixed time for the blocked thread and then just create a pt_note
    with zeroes to indicate the presence of the blocked thread.

    2) CRIU Approach :

    This makes use of the CRIU tool and checkpoints when a dump is called, collects
    the required details and continues the running process.
    * A self dump cannot be initiated using the command line CRIU which is similar
    to the limitation of gcore.
    * A system call to do the same is being implemented which would help us create
    a self dump.The system call is not upstream yet. We could explore that option as
    well.

    3) PTRACE (SEIZE + INTERRUPT) via kernel thread

    In this approach, a kernel thread will play the role of seizing and registering
    the states of the threads of the process to be dumped. We could make use of the
    PTRACE_SEIZE + PTRACE_INTERRUPT within the open() to stop the threads without
    SIGSTOP. However during self dump, we cannot make use of the PTRACE_SEIZE as a
    self seize isn't permitted. One option is to offload this to a kernel thread
    and let it capture the information. Once it is complete,the caller may be
    released, so that it could continue with the dump.

    * The open call reaches the kernel space during a self dump, a kernel thread
    is spawned to seize all the threads of the process including the caller (the
    process that called open) using a PTRACE_SEIZE.
    * A PTRACE_INTERRUPT is issued and the required information is collected.
    * On a self-dump, the kernel thread releases the caller, so that it can proceed
    with the dumping.


    APPENDIX:

    [1] http://www.redhat.com/archives/utrace-devel/2009-July/msg00149.html
    [2] http://www.redhat.com/archives/utrace-devel/2009-August/msg00006.html
    [3] http://lwn.net/Articles/419756//

    Thanking You.
    With Regards,
    Janani Venkataraman




    \
     
     \ /
      Last update: 2013-09-03 11:01    [W:0.042 / U:0.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site