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

Pavel Emelyanov xemul at parallels.com
Tue Jul 24 00:02:03 EDT 2012


On 07/23/2012 03:12 PM, Cyrill Gorcunov wrote:
> Otherwise we might not unmap the whole stack leaving
> a guard page in restoree memory map. Not a big deal
> but anyway.
> 
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
>  proc_parse.c |   20 ++++++++++++++++++++
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/proc_parse.c b/proc_parse.c
> index 0d80011..3c5c27c 100644
> --- a/proc_parse.c
> +++ b/proc_parse.c
> @@ -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?

>  		} else if (strstr(buf, "[vsyscall]")) {
>  			vma_area->vma.status |= VMA_AREA_VSYSCALL;
>  		} else if (strstr(buf, "[vdso]")) {



More information about the CRIU mailing list