Re: [criu] 1M guard page ruined restore

[Cyrill Gorcunov <gorcunov@gmail.com>]

On Wed, Jun 21, 2017 at 06:24:18PM -0700, Hugh Dickins wrote:
> > 
> > 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.

On my fedora24 too :) And I rather wonder why guard page is mentioned
here, because as far as I remember the only "cut off a guard page"
case was proc/$pid/[s]maps output. mmap() returned exact vma's start
address all the time, isn't it? Where the guard page is rather an
internal kernel's handling of page faults for growsdown areas.

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

	Cyrill