From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 COLOPre 07/26] libxc/restore: fix error handle of process_record Date: Mon, 29 Jun 2015 17:07:30 +0100 Message-ID: <1435594050.32500.373.camel@citrix.com> References: <1435213552-10556-1-git-send-email-yanghy@cn.fujitsu.com> <1435213552-10556-8-git-send-email-yanghy@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1435213552-10556-8-git-send-email-yanghy@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Yang Hongyang Cc: wei.liu2@citrix.com, wency@cn.fujitsu.com, andrew.cooper3@citrix.com, yunhong.jiang@intel.com, eddie.dong@intel.com, xen-devel@lists.xen.org, guijianfeng@cn.fujitsu.com, rshriram@cs.ubc.ca, Ian Jackson List-Id: xen-devel@lists.xenproject.org On Thu, 2015-06-25 at 14:25 +0800, Yang Hongyang wrote: ITYM "handling" in the subject. And perhaps "change" rather than "fix"? > If the err is RECORD_NOT_PROCESSED, and it is an optional record, > restore will still fail. There're two options to fix this, > a, setting rc to 0 when it is an optional record. > b, do the error handling in the caller. > We choose b because: > There will be another error type in COLO, which indicates a failover, > that needs to be handled in restore(), so moving the error handling out > to make the logic clearer...Otherwise, in process_record, > RECORD_NOT_PROCESSED is handled, and in restore another error type > returned from process_record is handled. > > Signed-off-by: Yang Hongyang > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > --- > tools/libxc/xc_sr_restore.c | 28 ++++++++++++++-------------- > 1 file changed, 14 insertions(+), 14 deletions(-) > > diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c > index fd45775..d5645e0 100644 > --- a/tools/libxc/xc_sr_restore.c > +++ b/tools/libxc/xc_sr_restore.c > @@ -569,19 +569,6 @@ static int process_record(struct xc_sr_context *ctx, struct xc_sr_record *rec) > free(rec->data); > rec->data = NULL; > > - if ( rc == RECORD_NOT_PROCESSED ) > - { > - if ( rec->type & REC_TYPE_OPTIONAL ) > - DPRINTF("Ignoring optional record %#x (%s)", > - rec->type, rec_type_to_str(rec->type)); > - else > - { > - ERROR("Mandatory record %#x (%s) not handled", > - rec->type, rec_type_to_str(rec->type)); > - rc = -1; > - } > - } > - > return rc; > } > > @@ -669,7 +656,20 @@ static int restore(struct xc_sr_context *ctx) There is a second caller of process_record in handle_checkpoint, so this change will result in a change of behaviour for that case, I think. If that is intentional then it ought to be mentioned in the commit log, since otherwise it looks a lot like this change is supposed to result in no overall difference. Ian. > else > { > rc = process_record(ctx, &rec); > - if ( rc ) > + if ( rc == RECORD_NOT_PROCESSED ) > + { > + if ( rec.type & REC_TYPE_OPTIONAL ) > + DPRINTF("Ignoring optional record %#x (%s)", > + rec.type, rec_type_to_str(rec.type)); > + else > + { > + ERROR("Mandatory record %#x (%s) not handled", > + rec.type, rec_type_to_str(rec.type)); > + rc = -1; > + goto err; > + } > + } > + else if ( rc ) > goto err; > } >