mm: taking into account a gurad page to find a space for a restorer vma

Actually a gurad page is a part of a stack vma and we don't want to remap
it by a restorer vma.

The crtools on restore find a place for a restorer vma, which will not
intersect with other VMAs. A guard page is a part of a stack VMA, if
we don't take into account it, we can place the restorer VMA on it and
that case is a bug.

Would not this lead to situation where we expand stack manually? Every new
c/r cycle add one page to the bottom of stack, no? No:

strace:
mmap(0x5f4d0e0cc000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_GROWSDOWN, -1, 0) =
0x5f4d0e0cc000

/proc/PID/maps:
5f4d0e0cd000-5f4d0e0cd000 rw-p 00000000 00:00 0
.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>

restorer.c

@@ -311,13 +311,6 @@ long __export_restore_task(struct task_restore_core_args *args)
 		if (!vma_entry_is(vma_entry, VMA_AREA_REGULAR))
 			continue;
 
-		/*
-		 * The kernel doesn't show stack guard pages on
-		 * proc output, so add pages here by hands.
-		 */
-		if (vma_entry_is(vma_entry, VMA_AREA_STACK))
-			vma_entry->start -= PAGE_SIZE;
-
 		if (sys_munmap((void *)vma_entry->start, vma_entry_len(vma_entry))) {
 			write_num_n_err(__LINE__);
 			goto core_restore_end;

util.c

@@ -44,6 +44,12 @@ void mark_stack_vma(unsigned long sp, struct list_head *vma_area_list)
 		if (in_vma_area(vma_area, sp)) {
 			vma_area->vma.status |= VMA_AREA_STACK;
 			vma_area->vma.flags  |= MAP_GROWSDOWN;
+
+			/*
+			 * The kernel doesn't show stack guard pages on
+			 * proc output, so add pages here by hands.
+			 */
+			vma_area->vma.start -= PAGE_SIZE;
 			return;
 		}
 	}