Re: [criu] 1M guard page ruined restore

From: Cyrill Gorcunov
Date: Thu Jun 22 2017 - 04:06:39 EST

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