[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