[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