From xen-devel-bounces@lists.xen.org Thu Feb 18 18:33:39 2016 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2016 18:33:39 +0000 Received: from lists.xenproject.org ([50.57.142.19] helo=lists.xen.org) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1aWTOV-0000Xs-QJ for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 18 Feb 2016 18:33:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWTLz-0001A6-Cc; Thu, 18 Feb 2016 18:31:03 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWTLy-0001A1-7a for xen-devel@lists.xen.org; Thu, 18 Feb 2016 18:31:02 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 3B/60-28972-5ED06C65; Thu, 18 Feb 2016 18:31:01 +0000 X-Env-Sender: prvs=849dfa6a4=Ian.Jackson@citrix.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1455820259!16347342!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1913 invoked from network); 18 Feb 2016 18:31:00 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Feb 2016 18:31:00 -0000 X-IronPort-AV: E=Sophos;i="5.22,466,1449532800"; d="scan'208";a="332698364" From: Ian Jackson MIME-Version: 1.0 Content-Length: 1777 Message-ID: <22214.3553.260609.617265@mariner.uk.xensource.com> Date: Thu, 18 Feb 2016 18:30:57 +0000 To: Ian Campbell Newsgroups: chiark.mail.xen.devel In-Reply-To: <1447933727.5647.51.camel@citrix.com> References: <564CC43B.1000904@ainfosec.com> <1447924858.5647.15.camel@citrix.com> <564DAA8D.5060305@citrix.com> <1447932195.5647.46.camel@citrix.com> <564DB393.3070805@citrix.com> <1447933727.5647.51.camel@citrix.com> X-Mailer: VM 8.1.0 under 23.4.1 (i486-pc-linux-gnu) X-DLP: MIA1 Cc: Andrew Cooper , Martin Osterloh , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] Current LibXL Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Ian Campbell writes ("Re: [Xen-devel] Current LibXL Status"): > The only one I can find which isn't one of this is > in=A0libxl__event_disaster, and that is only if the applications (or lang= uage > bindings) haven't provided a suitable disaster callback. libxl__event_disaster can currently happen in the following cases. Disasters which are specific to a specific requested event (type!=3D0): xc_domain_getinfolist failure (breaks reporting domain death, only xw_write failure for acknowledging disk eject (breaks reporting ejects, only) General disasters (type=3D=3D0) due to xenstore problems: POLLERR or POLLHUP on xenstore fd xs_check_watch fails (represents trouble on xenstore fd or with xenstore) xs_read for domain death check General disasters (type=3D=3D0) due to hypercall trouble: xenevtchn_pending fails other than with EAGAIN (unrequested) event other than POLLIN on evtchn fd General disasters (type=3D=3D0) due to syscall failure: poll syscall fails (unrequested) event other than POLLIN on self-pipe read() or write() fails on a self-pipe (other than EAGAIN/EWOULDBLOCK) waitpid() syscall fails General disasters (type=3D=3D0) induced by the application: waitpid reports ECHILD when we know we have a child (probably, something else in the process reaped it; arguably this should abort) application's childproc_hooks->reaped_callback failure Disasters are not reported unless it is impossible to proceed. So in general it is not possible for a process to recover from a disaster reported by libxl. But disasters are never expected. They should occur only if everything is totally doomed anyway. Having a daemon crash is a perfectly reasonable response. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel