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.107 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site