[CRIU] Re: [PATCH cr 07/11] restorer: remap private vmas to correct places

Andrew Vagin avagin at parallels.com
Mon Oct 15 14:10:27 EDT 2012


On Mon, Oct 15, 2012 at 08:28:27PM +0400, Pavel Emelyanov wrote:
> > diff --git a/restorer.c b/restorer.c
> > index 04337a9..75c09a0 100644
> > --- a/restorer.c
> > +++ b/restorer.c
> > @@ -337,6 +337,30 @@ long __export_restore_task(struct task_restore_core_args *args)
> >  		if (!vma_entry_is(vma_entry, VMA_AREA_REGULAR))
> >  			continue;
> >  
> > +		if (!vma_priv(vma_entry))
> > +			continue;
> > +
> > +		va = sys_mremap(vma_entry->shmid,
> > +				vma_entry_len(vma_entry), vma_entry_len(vma_entry),
> > +				MREMAP_MAYMOVE | MREMAP_FIXED, vma_entry->start);
> 
> What if the vma_entry->shmid is busy with another "soon to be remapped" vma?

Yes, it's a problem, I'm going to fix it soon.

> 
...
> > +			goto core_restore_end;
> > +		}
> > +	}
> > +
> > +	/*
> > +	 * OK, lets try to map new one.
> > +	 */
> > +	for (vma_entry = args->tgt_vmas; vma_entry->start != 0; vma_entry++) {
> > +		if (!vma_entry_is(vma_entry, VMA_AREA_REGULAR))
> > +			continue;
> > +
> > +		if (vma_priv(vma_entry))
> > +			continue;
> 
> Double pass over vmas list. Can we avoid it?
We can't, because vma_entry->start can be busy with "another "soon to be
remapped" vma"
> 
> > +
> >  		va = restore_mapping(vma_entry);
> >  
> >  		if (va != vma_entry->start) {
> > 
> 
> 


More information about the CRIU mailing list