xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	Jiang Yunhong <yunhong.jiang@intel.com>,
	Dong Eddie <eddie.dong@intel.com>,
	xen devel <xen-devel@lists.xen.org>,
	Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [RFC Patch v4 7/9] correct xc_domain_save()'s return value
Date: Mon, 22 Sep 2014 15:06:37 +0100	[thread overview]
Message-ID: <54202CED.3040508@citrix.com> (raw)
In-Reply-To: <1411391615.18331.86.camel@kazak.uk.xensource.com>

On 22/09/14 14:13, Ian Campbell wrote:
> On Mon, 2014-09-22 at 14:03 +0100, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [Xen-devel] [RFC Patch v4 7/9] correct xc_domain_save()'s return value"):
>>> libxc doesn't know that, if it is important then it seems like the
>>> failure + errno ought to be marshalled across the IPC link.
>> Yes, but ...
>>
>>> It may be that this can be easily handled in
>>> libxl__srm_callout_sendreply + helper_getreply. Ian J -- what do you
>>> think?
>> ... while that would be possbile, we have another option.
>>
>> We could say that the callbacks return errno values.  That would
>> simplify the API and avoid having the IPC involve accesses to global
>> variables (ie, things not in the functions' parameter lists).
>>
>> If we do that then it becomes the responsibility of xc_domain_save to
>> either change its own API to return errno, or to save the callback's
>> return value in errno.
> Hrm. libxc is already a complete mess wrt error returning/handling
> because some proportion of the code incorrectly does/assumes this sort
> of thing is happening (because people were confused about the syscall
> returns from the kernel vs. process context). Having a place in libxc
> where this is now done on purpose seems a bit like setting the rope on
> fire to me...
>
> Ian.
>

libxc is an absolute mess, but this is far from the only codepath (even
in xc_domain_save()) which ends up like this.

The *only* safe assumption is that ==0 is success and !=0 is failure for
xc_domain_save(), and errno may or may not be relevant, whether rc is -1
or not.

For the suspend callback itself, I have encountered 3 different error
schemes which stem from a complete lack of expectations set out beside
the function pointer definition in xenguest.h, which is why I had to
copy the old "!=0" check in migration v2.  Even intree in the past, -1
and 1 have been used for errors from this function pointer.


It is my opinion that it is not worth changing any of the error handling
until someone does all of libxc and makes it all consistent.  The risk
for introducing subtle bugs into in (and out-of-) tree callers is just
too high, and this change alone does not fix xc_domain_save() to be
consistent.

~Andrew

  parent reply	other threads:[~2014-09-22 14:06 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-22  5:59 [RFC Patch v4 0/9] Some bugfix patches Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 1/9] copy the correct page to memory Wen Congyang
2014-09-22 14:38   ` Ian Campbell
2014-09-22  5:59 ` [RFC Patch v4 2/9] csum the correct page Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 3/9] pass correct file to qemu if we use blktap2 Wen Congyang
2014-12-11 16:45   ` George Dunlap
2014-12-13 17:06     ` Wei Liu
2014-12-15 10:18       ` Ian Campbell
2014-12-15 11:10         ` George Dunlap
2014-09-22  5:59 ` [RFC Patch v4 4/9] read nictype from xenstore Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 5/9] check if mfn is supported by IOCTL_PRIVCMD_MMAPBATCH before calling ioctl() Wen Congyang
2014-09-22 14:26   ` Ian Campbell
2014-09-23  1:40     ` Wen Congyang
2014-09-23 10:08       ` Ian Campbell
2014-09-24  1:36         ` Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 6/9] don't zero out ioreq page and handle the pended I/O after resuming Wen Congyang
2014-09-22 11:22   ` Jan Beulich
2014-09-22  5:59 ` [RFC Patch v4 7/9] correct xc_domain_save()'s return value Wen Congyang
2014-09-22  7:30   ` Olaf Hering
2014-09-22  7:34     ` Wen Congyang
2014-09-22  7:46       ` Olaf Hering
2014-09-22  8:06         ` Wen Congyang
2014-09-22  8:13           ` Olaf Hering
2014-09-22  8:24             ` Wen Congyang
2014-09-22  8:41             ` Wen Congyang
2014-09-22 12:42           ` Ian Campbell
2014-09-22 13:03             ` Ian Jackson
2014-09-22 13:13               ` Ian Campbell
2014-09-22 13:57                 ` [PATCH RFC 0/3] " Ian Jackson
2014-09-22 13:58                   ` Ian Campbell
2014-09-22 14:00                     ` Ian Campbell
2014-09-22 13:58                   ` [PATCH 1/3] libxl: save helper: remove redundant declaration Ian Jackson
2014-09-22 13:58                   ` [PATCH 2/3] libxl: save helper: transport errno with all callback return values Ian Jackson
2014-09-22 13:58                   ` [PATCH 3/3] libxl: save/restore callbacks: enforce a useful errno value Ian Jackson
2014-09-22 14:07                     ` Ian Campbell
2014-09-22 14:08                       ` Ian Jackson
2014-09-22 14:06                 ` Andrew Cooper [this message]
2014-09-23  2:14                   ` [RFC Patch v4 7/9] correct xc_domain_save()'s return value Wen Congyang
2014-09-23  9:00                     ` Andrew Cooper
2014-09-23  9:10                       ` Wen Congyang
2014-09-23  9:25                         ` Andrew Cooper
2014-09-23  9:29                           ` Wen Congyang
2014-09-23 10:09                             ` Ian Campbell
2014-09-23  9:52                           ` Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 8/9] store correct format into tapdisk-params/params Wen Congyang
2014-09-22 14:37   ` Ian Campbell
2014-09-23  2:07     ` Wen Congyang
2014-09-23 10:11       ` Ian Campbell
2014-09-23 10:32         ` Wen Congyang
2014-09-22  5:59 ` [RFC Patch v4 9/9] update libxl__device_disk_from_xs_be() to support blktap device Wen Congyang
2014-09-22 15:08   ` Ian Campbell
2014-09-23  3:07     ` Wen Congyang
2014-09-23 10:12       ` Ian Campbell
2014-09-22 12:44 ` [RFC Patch v4 0/9] Some bugfix patches Ian Campbell
2014-09-22 12:56   ` Wen Congyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54202CED.3040508@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=eddie.dong@intel.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=olaf@aepfle.de \
    --cc=wency@cn.fujitsu.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yanghy@cn.fujitsu.com \
    --cc=yunhong.jiang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).