[CRIU] Fwd: [PATCH] page-xfer: repair bug with check_pagehole_in_parent

Pavel Tikhomirov snorcht at gmail.com
Fri Apr 18 03:13:46 PDT 2014


Sorry, missed CRML.


---------- Forwarded message ----------
From: Pavel Tikhomirov <snorcht at gmail.com>
Date: 2014-04-18 14:11 GMT+04:00
Subject: Re: [PATCH] page-xfer: repair bug with check_pagehole_in_parent
To: Pavel Emelyanov <xemul at parallels.com>


I don't think that we need some special test. This patch only checks on
dumping hole that in parent images data for that hole exists.


Best Regards, Tikhomirov Pavel.


2014-04-18 14:06 GMT+04:00 Pavel Tikhomirov <snorcht at gmail.com>:

It all don't create real bug now. It just don't checks, what it really need
> to check, as I thought.
>
> I try to use check_pagehole_in_parent in dedup on unmap patch which I
> sent before, and
> this correction is critical for it.
>
>
> Best Regards, Tikhomirov Pavel.
>
>
> 2014-04-18 14:00 GMT+04:00 Pavel Emelyanov <xemul at parallels.com>:
>
> On 04/18/2014 01:50 PM, Tikhomirov Pavel wrote:
>> > 1)it didn't find real pages it had only one step into iterative
>> snapshots
>> > but what if real page is on the third level?
>> >
>> > patch adds recoursive check in previous images
>> >
>> > 2)it did provide whole intersected pagemap, but it will be more
>> > convinient to print only intersection part.
>>
>> Was this all was caught by zdtm? If no, then it's worth creating
>> a stress test on stackable images. Would you?
>>
>> > Signed-off-by: Tikhomirov Pavel <snorcht at gmail.com>
>> > ---
>> >  page-xfer.c | 18 +++++++++++++++---
>> >  1 file changed, 15 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/page-xfer.c b/page-xfer.c
>> > index 56e8575..0678b54 100644
>> > --- a/page-xfer.c
>> > +++ b/page-xfer.c
>> > @@ -504,7 +504,7 @@ static int check_pagehole_in_parent(struct
>> page_read *p, struct iovec *iov)
>> >       off = (unsigned long)iov->iov_base;
>> >       end = off + iov->iov_len;
>> >       while (1) {
>> > -             struct iovec piov;
>> > +             struct iovec piov, tiov;
>> >               unsigned long pend;
>> >
>> >               ret = seek_pagemap_page(p, off, true);
>> > @@ -512,7 +512,20 @@ static int check_pagehole_in_parent(struct
>> page_read *p, struct iovec *iov)
>> >                       return -1;
>> >
>> >               pagemap2iovec(p->pe, &piov);
>> > -             pr_debug("\tFound %p/%zu\n", piov.iov_base, piov.iov_len);
>> > +             pend = (unsigned long)piov.iov_base + piov.iov_len;
>> > +
>> > +             tiov.iov_base = (void*)off;
>> > +             tiov.iov_len = min(pend, end) - off;
>> > +             if (!p->pe->in_parent) {
>> > +                     pr_debug("\tFound %p/%zu\n", tiov.iov_base,
>> tiov.iov_len);
>> > +             } else {
>> > +                     if (p->parent)
>> > +                             check_pagehole_in_parent(p->parent,
>> &tiov);
>> > +                     else {
>> > +                             pr_err("No parent, though pagemap is
>> in_parent");
>> > +                             return -1;
>> > +                     }
>> > +             }
>> >
>> >               /*
>> >                * The pagemap entry in parent may heppen to be
>> > @@ -520,7 +533,6 @@ static int check_pagehole_in_parent(struct
>> page_read *p, struct iovec *iov)
>> >                * we should go ahead and check the remainder.
>> >                */
>> >
>> > -             pend = (unsigned long)piov.iov_base + piov.iov_len;
>> >               if (end <= pend)
>> >                       return 0;
>> >
>> >
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140418/af375915/attachment-0001.html>


More information about the CRIU mailing list