Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752010AbdFVBY2 (ORCPT ); Wed, 21 Jun 2017 21:24:28 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:34542 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751458AbdFVBY1 (ORCPT ); Wed, 21 Jun 2017 21:24:27 -0400 Date: Wed, 21 Jun 2017 18:24:18 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Dmitry Safonov cc: Linus Torvalds , Oleg Nesterov , Cyrill Gorcunov , Hugh Dickins , Andrey Vagin , LKML , Pavel Emelyanov , Andrew Morton , Adrian Reber , Michael Kerrisk Subject: Re: [criu] 1M guard page ruined restore In-Reply-To: <8ff61433-f154-6c9e-91b2-1857b5eff90c@virtuozzo.com> Message-ID: References: <20170620075206.GB1909@uranus.lan> <20170621152256.GC31050@uranus> <20170621155730.GA32554@redhat.com> <20170621160410.GF31050@uranus> <20170621170129.GA32752@redhat.com> <2551ee70-a4b6-4f38-7d3a-4eb2cddc96a5@virtuozzo.com> <20170621173115.GA28723@redhat.com> <8ff61433-f154-6c9e-91b2-1857b5eff90c@virtuozzo.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1838 Lines: 42 On Wed, 21 Jun 2017, Dmitry Safonov wrote: > 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 That does go into rather more detail than I like to see: I suppose the man pages on my machines are rather old, and only show the first two innocuous sentences about MAP_GROWSDOWN. Michael, v4.12-rc6 enlarges the stack guard gap from one page to 256 pages (by default). But quite what the man page ought to say will depend on the outcome of the discussion in the lkp-robot thread. (Or perhaps it isn't a discussion, but me feeling over-anxious about how Linus has decided.) Maybe the robot will settle it. Hugh