[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