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

[Cyrill Gorcunov]

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")

 - 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)

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

	Cyrill