Messages in this thread | | | Date | Fri, 25 May 2012 20:12:24 +0900 | From | YOSHIDA Masanori <> | Subject | Re: [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. >
| |