<div dir="ltr"><div>Hi Pavel,</div><div><br></div><div>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.</div><div>I will query if stuck somewhere in code. I think we can start with design discussion. <br></div><div> <br></div><div>Some queries related to new approach:</div><div>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?</div><div><br></div><div>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)?<br></div><div><br></div><div>3) iovs generation for shared mapping are ignored and shared mapping is handled separately. Will new approach handle shared memory similarly?<br></div><div><br></div><div>4) Freeze - collect vmas - Unfreeze : How we go about handling following events -<br></div><div> a) process does something such that vma gets modified</div><div> - we can't ignore such mappings</div><div> - we can't freeze single process again, becomes inconsistent with other tree processes<br></div><div> b) one of the process in pstree dies<br></div><div><br></div><div>- Abhishek<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 15, 2019 at 1:15 PM Pavel Emelianov <<a href="mailto:xemul@virtuozzo.com">xemul@virtuozzo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/14/19 9:08 PM, Abhishek Dubey wrote:<br>
> Hi,<br>
> <br>
> 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.<br>
> <br>
> 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 :<br>
> 1) A memory region could be read from target process only if read access is set.<br>
<br>
Of course, that's why there's a call to PARASITE_CMD_MPROTECT_VMAS in parasite_dump_pages_seized.<br>
We should just skip those mappnigs for the new approach.<br>
<br>
> 2) [vvar] region turned out to be one of unreadable region, although read permission is set. Are there more such unreadable regions expected?<br>
<br>
There's a generate_vma_iovs call that checks if we should try to dump the vma in question at all.<br>
If I'm not mistaken, it should skip all the "bad" vmas for you.<br>
<br>
-- Pavel<br>
</blockquote></div>