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

Cyrill Gorcunov gorcunov at openvz.org
Tue Jul 24 02:20:23 EDT 2012


On Tue, Jul 24, 2012 at 08:02:03AM +0400, Pavel Emelyanov wrote:
> > @@ -146,6 +146,26 @@ int parse_smaps(pid_t pid, struct list_head *vma_area_list, bool use_map_files)
> >  		if (strstr(buf, "[stack")) {
> >  			vma_area->vma.status |= VMA_AREA_REGULAR | VMA_AREA_STACK;
> >  			vma_area->vma.flags  |= MAP_GROWSDOWN;
> > +
> > +			/*
> > +			 * For a moment we can't figure out if
> > +			 * stack is allocated with MAP_GROWSUP,
> > +			 * need to add some flag into a kernel.
> > +			 *
> > +			 * But still for stack the kernel hides guard
> > +			 * page so we add this page manually.
> > +			 *
> > +			 * For MAP_GROWSDOWN one page on bottom is hidden,
> > +			 * for MAP_GROWSUP the reverse -- one page on top.
> > +			 */
> > +
> > +			if (vma_area->vma.start < PAGE_SIZE) {
> > +				pr_err("Can't handle stack guard page on %d's map %lu\n",
> > +				       pid, vma_area->vma.start);
> > +				goto err;
> > +			}
> > +			vma_area->vma.start -= PAGE_SIZE;
> > +
> 
> 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. Actually the task's stack is one page bigger than we find it
from proc output. It's a not big deal for a while (since we don't support
multi-time c/r yet) but might become a problem in future.

	Cyrill


More information about the CRIU mailing list