[CRIU] [PATCH 2/2] mem: Don't assume guard page is returned in procfs with new kernels

[Oleg Nesterov]

On 06/20, Cyrill Gorcunov wrote:
>
> On Tue, Jun 20, 2017 at 03:02:47PM +0200, Oleg Nesterov wrote:
> > > --- a/criu/cr-restore.c
> > > +++ b/criu/cr-restore.c
> > > @@ -1812,7 +1812,8 @@ static int restore_task_with_children(void *_arg)
> > >
> > >  	timing_stop(TIME_FORK);
> > >
> > > -	if (unmap_guard_pages(current))
> > > +	if (kdat.mm_guard_page_maps &&
> > > +	    unmap_guard_pages(current))
> >
> > can't resist... I feel that unmap_guard_pages() logic is not really right and
> > this helper can be simply removed even with stack-guard... but I can be easily
> > wrong and this is off-topic right now.
>
> You know, we're running tests now and found that not calling unmap_guard_pages
> on new kernel left some pages on restored process. They are came from other
> restore code which assumes that on growsdown flag page-size need to added/removed.
> So as a fast fix unmap_guard_pages still should be called.

Hmm, confused. After this kernel patch unmap_guard_pages() makes no sense, it
should not be called. I think you see the failures exactly because you need to
fix more GROWSDOWN checks?

And. Please forget about the kernel patch for the moment. Lets suppose that we
disable all this logic unconditionally (to remind, this is what we will probably
do) and run criu with the old kernel.

Now, iiuc criu will mostly work. Usually there is nothing in the hidden guard
page. But most probably you have some test-cases which test this functionality,
say, a test-case can munmap the guard page, then check that the whole stack was
restored correctly?

IOW, could you tell us which test-cases should certainly fail if we remove or
disable the stack-guard-page hacks in criu? So that we can distinguish (I mean
ignore ;) these failures from the real problems?

Oleg.