lkml.org 
[lkml]   [2012]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/4 V2] introduce: livedump
    Hi, Peter

    Thank you for quick reply.

    Yes, I know that PF in NMI handling is dangerous, and so livedump doesn't
    protect such pages that can be updated during NMI handling.
    Such pages are listed in [3/4] as "sensitive pages".

    Currently, I regard the following pages as sensitive pages in [3/4].
    - Kernel/Exception/Interrupt stacks
    - Page table structure
    - All task_struct
    - ".data" section of kernel
    - All per_cpu areas

    However, I can't assure these pages are enough to avoid PF in NMI handling.
    Do you have any idea to enumerate sensitive pages correctly?

    Thank you.


    On 2012/05/25 18:25, Peter Zijlstra wrote:
    > On Fri, 2012-05-25 at 18:12 +0900, YOSHIDA Masanori wrote:
    >> Live Dump is based on Copy-on-write technique. Basically processing is
    >> performed in the following order.
    >> (1) Suspends processing of all CPUs.
    >> (2) Makes pages (which you want to dump) read-only.
    >> (3) Resumes all CPUs
    >> (4) On page fault, dumps a page including a fault address.
    >
    > Suppose a PF is in progress when all this happens, you mark all RO, then
    > an NMI happens, from the NMI context we'll generate another PF to update
    > a vmap area, this will again PF because you mucked about and marked
    > things RO.
    >
    > You're now at 3 PFs, which is instant reboot.
    >
    > I don't think this is going to work.
    >



    \
     
     \ /
      Last update: 2012-05-25 13:41    [W:0.027 / U:1.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site