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

[Pavel Emelyanov]

On 07/24/2012 10:20 AM, Cyrill Gorcunov wrote:
> 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.

Why? We'll try to read this page contents when dumping and may catch sigsegv.

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