[CRIU] [PATCH 04/11 v3] criu: lazy-pages: replace page list with IOVs list

[Pavel Emelyanov]

>>> @@ -591,33 +627,33 @@ static int uffd_handle_page(struct lazy_pages_info *lpi, __u64 address,
>>>
>>>  static int handle_remaining_pages(struct lazy_pages_info *lpi, void *dest)
>>>  {
>>> -     struct uffd_pages_struct *uffd_pages;
>>> -     int rc;
>>> +     struct lazy_iovec *lazy_iov;
>>> +     int nr_pages, i, err;
>>> +     unsigned long addr;
>>>
>>> -     list_for_each_entry(uffd_pages, &lpi->pages, list) {
>>> -             pr_debug("Checking remaining pages 0x%lx (flags 0x%x)\n",
>>> -                      uffd_pages->addr, uffd_pages->flags);
>>> -             if (uffd_pages->flags & UFFD_FLAG_SENT)
>>> -                     continue;
>>> +     lpi->pr.reset(&lpi->pr);
>>>
>>> -             rc = uffd_handle_page(lpi, uffd_pages->addr, dest);
>>> -             if (rc < 0) {
>>> -                     pr_err("Error during UFFD copy\n");
>>> -                     return -1;
>>> -             }
>>> +     list_for_each_entry(lazy_iov, &lpi->iovs, l) {
>>> +             nr_pages = lazy_iov->len / PAGE_SIZE;
>>> +
>>> +             for (i = 0; i < nr_pages; i++) {
>>> +                     addr = lazy_iov->base + i * PAGE_SIZE;
>>>
>>> -             uffd_pages->flags |= UFFD_FLAG_SENT;
>>> +                     err = uffd_handle_page(lpi, addr, dest);
>>
>> This place looks dangerous. The iovs can be quite large and requesting the whole
>> IOV during single #PF handling may slow the restored tree down significantly.
> 
> We never request more than one page at #PF time. The entire IOVs are
> requested only after 5 secs timeout

But here's the for (i = 0; i < nr_pages; i++) loop which does so, doesn't it?

-- Pavel