From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Hongyang Subject: Re: [PATCH v3 COLOPre 07/26] libxc/restore: fix error handle of process_record Date: Fri, 3 Jul 2015 11:12:35 +0800 Message-ID: <5595FDA3.6000208@cn.fujitsu.com> References: <1435213552-10556-1-git-send-email-yanghy@cn.fujitsu.com> <1435213552-10556-8-git-send-email-yanghy@cn.fujitsu.com> <1435594050.32500.373.camel@citrix.com> <55926546.9080907@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55926546.9080907@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: Ian Campbell 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 06/30/2015 05:45 PM, Yang Hongyang wrote: > > > On 06/30/2015 12:07 AM, Ian Campbell wrote: >> 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. > > Ah, seems I missed the other caller, good catch, and I will fix it in the > next version. > >> >> If that is intentional then it ought to be mentioned in the commit log, I rechecked the process_record in handle_checkpoint, it just return the error code, finally, the error will be handled by the upper caller in restore(), so it is intentional, I wll mention this 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; >>> } >>> >> >> >> . >> > -- Thanks, Yang.