Re: [criu] 1M guard page ruined restore

From: Dmitry Safonov <dsafonov@virtuozzo.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	Hugh Dickins <hughd@google.com>, Andrey Vagin <avagin@openvz.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Andrew Morton <akpm@linuxfoundation.org>,
	Adrian Reber <areber@redhat.com>, Michael Kerrisk <mtk@man7.org>
Subject: Re: [criu] 1M guard page ruined restore
Date: Wed, 21 Jun 2017 20:52:59 +0300	[thread overview]
Message-ID: <8ff61433-f154-6c9e-91b2-1857b5eff90c@virtuozzo.com> (raw)
In-Reply-To: <20170621173115.GA28723@redhat.com>

On 06/21/2017 08:31 PM, Oleg Nesterov wrote:
> On 06/21, Dmitry Safonov wrote:
>>
>> The only question I have - how is it connected to guard page?
> 
> Because with stack guard page do_page_fault() almost never needs to
> call expand_stack(), thus this check was almost never tested, I guess.
> Probably it should go away now.
> 
> I'll write the changelog and patch tomorrow, unless someone does this
> before.

Ugh, maybe it's also worth now to update man 2 mmap.

At this moment, mmap() will no more return address one page lower
and "guard" is no more a page:

> MAP_GROWSDOWN
>        This flag is used for stacks. It indicates to the kernel virtual
>        memory system that the mapping should extend downward in       
>        memory. The return address is one page lower than the memory
>        area that is actually created in the process's virtual address
>        space. Touching an address in the "guard" page below the mapping
>        will cause the mapping to grow by a page. This growth can be
>        repeated until the mapping grows to within a page of the high end
>        of the next lower mapping, at which point touching the "guard"
>        page will result in a  SIGSEGV signal.

CC'ing Michael

-- 
              Dmitry