Subject: Re: [criu] 1M guard page ruined restore
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>
References: <20170620075206.GB1909@uranus.lan>
 <alpine.LSU.2.11.1706200259080.11599@eggly.anvils>
 <20170621152256.GC31050@uranus> <20170621155730.GA32554@redhat.com>
 <20170621160410.GF31050@uranus> <20170621170129.GA32752@redhat.com>
 <a747d0be-ddf9-d338-06de-223337a03a67@virtuozzo.com>
 <2551ee70-a4b6-4f38-7d3a-4eb2cddc96a5@virtuozzo.com>
 <20170621173115.GA28723@redhat.com>
From: Dmitry Safonov <dsafonov@virtuozzo.com>
Message-ID: <8ff61433-f154-6c9e-91b2-1857b5eff90c@virtuozzo.com>
Date: Wed, 21 Jun 2017 20:52:59 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <20170621173115.GA28723@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2017 17:53:18.6890 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1739
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1251
Lines: 32

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