[CRIU] More uffd related questions (Error (page-read.c:128): Missing 7fff408d8000 in parent pagemap)

[Pavel Emelyanov]

On 11/30/2015 01:57 PM, Adrian Reber wrote:
> On Mon, Nov 30, 2015 at 01:44:00PM +0300, Pavel Emelyanov wrote:
>> On 11/30/2015 01:26 PM, Adrian Reber wrote:
>>> On Mon, Nov 30, 2015 at 01:24:30PM +0300, Pavel Emelyanov wrote:
>>>>
>>>>>> This is mm.img part, while page-read engine deals with pagemap-xxx.img files where
>>>>>> triplets of [start len in_parent] sit.
>>>>>
>>>>> Ah, okay. This is my error. The page I am trying to copy does indeed not
>>>>> exist in the pagemap:
>>>>>
>>>>>         {
>>>>>             "vaddr": "0x7f8025f6e000", 
>>>>>             "nr_pages": 5
>>>>>         }, 
>>>>>         {
>>>>>             "vaddr": "0x7fff408d9000", 
>>>>>             "nr_pages": 3
>>>>>         }, 
>>>>>         {
>>>>>             "vaddr": "0x7fff409c2000", 
>>>>>             "nr_pages": 2
>>>>>         }
>>>>>
>>>>> So to decide which pages I have to copy I only have to look at the content
>>>>> of pagemap-xxx.img and not mm.img, right? Good to know.
>>>>
>>>> Yes, the pagemap.img describes the physical memory dumped into the image files.
>>>
>>> Going over all vma entries with something like
>>>
>>>  list_for_each_entry(vma, vmas, list) {
>>>
>>> How do I know if an area has been dumped or not? 
>>
>> If it's on restore, then the list is likely got from image, isn't it?
> 
> It is during restore, yes. I currently don't understand the difference
> between mm.img and pagemap.img. In mm.img I see a couple of pages in
> 
>                 {
>                     "start": "0x7fff408ba000", 
>                     "end":   "0x7fff408dc000", 

That's not "a couple". This range is 34 pages length!

>                     "pgoff": 0, 
>                     "shmid": 0, 
>                     "prot": "PROT_READ | PROT_WRITE", 
>                     "flags": "MAP_PRIVATE | MAP_ANON | MAP_GROWSDOWN", 
>                     "status": "0x201", 
>                     "fd": -1, 
>                     "fdflags": "0x0"
>                 }, 
> 
> in pagemap.img it tells me only 5 pages in this range of 22 pages have
> actually been dumped:
> 
>         {
>             "vaddr": "0x7fff408d9000", 
>             "nr_pages": 3
>         }, 

This map is last 3 pages from the previous vma.

>         {
>             "vaddr": "0x7fff409c2000", 
>             "nr_pages": 2
>         }

These are pages 26 and 27 (I did off-by-one probably :) ).

> 
> I have only a single pages-1.img.
> 
> So if I want to loop over all pages how do I know which pages have
> actually been dumped? How do I know the difference between the 5 pages
> in pagemap.img and the 22 pages in mm.img in that memory area?

The mm.img describes which virtual address are "mmap"-ed. In your case
there's a mapping starting at 0x7fff408ba000 and having 34 _virtual_ pages
in it.

The pagemap.img shows where to put _physical_ pages. The vaddr:nr_pages
is the place where to put next portion from pages.img file. In your case
you should take 2 pages from pages.img and put them at 26'th page of
your area (0x7fff409c2000 starting address) and then take 3 more pages
and put them at the 31'th one (at 0x7fff408d9000).

CRIT doesn't show objects in a sorted manner, but the pagemap file has
entries sorted by vaddr.

-- Pavel