[CRIU] Re: [PATCH] Take into account stack guard page size in parse_smaps

[Pavel Emelyanov]

On 07/24/2012 11:15 AM, Cyrill Gorcunov wrote:
> On Tue, Jul 24, 2012 at 11:01:11AM +0400, Pavel Emelyanov wrote:
>> On 07/24/2012 10:56 AM, Cyrill Gorcunov wrote:
>>> On Tue, Jul 24, 2012 at 10:31:44AM +0400, Pavel Emelyanov wrote:
>>>>>>
>>>>>> This will affect the dump process as well -- we will dump one page more on the target task's stack.
>>>>>> Is that OK?
>>>>>
>>>>> Yeah, it's ok.
>>>>
>>>> Why? We'll try to read this page contents when dumping and may catch sigsegv.
>>>
>>> No, as far as I remember this page never has present bit and our dumper simply
>>> find it as not loaded into memory and will not dump its contents.
>>
>> This page is technically out of any mappings and reading pagemap for
>> those is not ... safe. Is it?
> 
> Look, here is two problems actually in no taking this page into account
> on dumping procedure
> 
>  - if it's not added into VMA size while being dumped we do shrink program
>    stack at dumping procedure and once we support mulishot c/r we end up
>    in situation where we might simply loose stack vma completely after
>    some c/r session (simply because kernel accept "size" at mmap call
>    but cuts off this page internally and report us this vma as "size-page")

NAK. We're talking about the guard page, which is added by kernel always.

>  - reading pagemap should not be a problem since pagemap operates on page
>    level rather than vma level, and on page level this guard area lacks
>    "present" bit (the kernel actually might expand stack if needed though,
>     see handle_pte_fault -> do_anonymous_page)

NAK again. pagemap works on pte level (how could it report swapout pages?).

> maybe we should poke Konstantin just to make sure (I believe he has worked
> on this area) ?

Hat-trick NAK. He's on vacation ;)

> 	Cyrill
> .
>