: [CRIU] [PATCH] restorer: Make sure the protection on code/data mm areas do fit the kernel requirements

[Cyrill Gorcunov]

On Fri, Apr 13, 2012 at 07:02:30PM +0400, Cyrill Gorcunov wrote:
> On Fri, Apr 13, 2012 at 06:59:25PM +0400, Pavel Emelyanov wrote:
> > > +	sys_mmap((void *)args->mm.mm_start_code, PAGE_SIZE, prot, flags, -1, 0);
> > > +	ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_START_CODE, (long)args->mm.mm_start_code, 0);
> > > +	sys_munmap((void *)args->mm.mm_start_code, PAGE_SIZE);
> > > +
> > > +	sys_mmap((void *)args->mm.mm_end_code, PAGE_SIZE, PROT_EXEC | PROT_READ, flags, -1, 0);
> > > +	ret |= sys_prctl_safe(PR_SET_MM, PR_SET_MM_END_CODE, (long)args->mm.mm_end_code, 0);
> > > +	sys_munmap((void *)args->mm.mm_end_code, PAGE_SIZE);
> > 
> > 
> > This is much nicer. Can we tune this a little bit more, i.e. like this
> > 
> > sys_mmap(code_start, code_end - code_start, ...)
> > sys_prctl(PR_SET_MM_START_CODE)
> > sys_prctl(PR_SET_MM_END_CODE)
> > sys_munmap()
> > 
> > i.e. mmap only one mapping per PR_SET_MM, not two?
> 
> I tried this, but it not always work, because .text and
> .data VMAs can cover really big space and we fail. Ie
> it will work sometimes, sometimes it'll fail. Better to
> stick with one which work always ;)

More precisely, imagin the data_start and data_end will look like
covering a number of VMAs including one we use for shared data
for restorer itself, thus such mmap() attempt will fail.

	Cyrill