[CRIU] GSoC: Boot up week

[Abhishek Dubey]

Hi Pavel,

I have gone through the cr_pre_dump_tasks() function tree and quite
comfortable with parts of it. Compel stuff seem bit difficult to digest in
one go.
I will query if stuck somewhere in code. I think we can start with design
discussion.

Some queries related to new approach:
1) We need to replace page pipe with user-space supplied buffer. There is
list of pipes in struct page_pipe. If I got it correct then, pipe buffer in
the list has to be replaced with user-supplied buffer and these buffer
exhibit same properties as of pipes in current implementation?

2) We finalized user space buffer for process_vm_readv to be of fixed size.
How do we go deciding best size (=max size of pipe)?

3) iovs generation for shared mapping are ignored and shared mapping is
handled separately. Will new approach handle shared memory similarly?

4) Freeze - collect vmas - Unfreeze : How we go about handling following
events -
         a) process does something such that vma gets modified
              - we can't ignore such mappings
              - we can't freeze single process again, becomes inconsistent
with other tree processes
         b) one of the process in pstree dies

- Abhishek

On Wed, May 15, 2019 at 1:15 PM Pavel Emelianov <xemul at virtuozzo.com> wrote:

> On 5/14/19 9:08 PM, Abhishek Dubey wrote:
> > Hi,
> >
> > I have tried suggested way of running zdtm test suite and played with
> CRIT. I am going through cr_pre_dump_tasks() function-tree. Please point
> out, if I must know any other necessary piece of code.
> >
> > I have used process_vm_readv() to copy pages, listed by parsing
> /proc/PID/maps of target process (a simple process that does mmap) and made
> following observations :
> > 1) A memory region could be read from target process only if read access
> is set.
>
> Of course, that's why there's a call to PARASITE_CMD_MPROTECT_VMAS in
> parasite_dump_pages_seized.
> We should just skip those mappnigs for the new approach.
>
> > 2) [vvar] region turned out to be one of unreadable region, although
> read permission is set. Are there more such unreadable regions expected?
>
> There's a generate_vma_iovs  call that checks if we should try to dump the
> vma in question at all.
> If I'm not mistaken, it should skip all the "bad" vmas for you.
>
> -- Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20190522/ee7e6df4/attachment.html>