From patchwork Fri Dec 27 16:32:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: George Dunlap X-Patchwork-Id: 11311277 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8E4BE6C1 for ; Fri, 27 Dec 2019 16:33:47 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6A2E120CC7 for ; Fri, 27 Dec 2019 16:33:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="PYtPlCMR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A2E120CC7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iksXc-0001Xj-TN; Fri, 27 Dec 2019 16:32:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iksXc-0001Xa-2P for xen-devel@lists.xenproject.org; Fri, 27 Dec 2019 16:32:44 +0000 X-Inumbo-ID: 7c819ee2-28c6-11ea-9c5f-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7c819ee2-28c6-11ea-9c5f-12813bfff9fa; Fri, 27 Dec 2019 16:32:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1577464354; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yB0bvCUV+fmVOFW7FGeLqFzKS17AeUTzidjyGeYkTts=; b=PYtPlCMRk67WMHVeXv2o2JlkklkVzNAquXjgLLhqPzLSwLf7unPZD6/0 LmYmcJranx7IeDBjvwF6/PH5lRvPRlOr/5Hx64YsHOPwU3pg86kxw9b6n 9V2dX03udP3fa6vgxF9MtC+8Dc0me8BgfM9yVwRPm8XxVVzVMqFLlZPbr w=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=george.dunlap@citrix.com; spf=Pass smtp.mailfrom=George.Dunlap@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of george.dunlap@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="George.Dunlap@citrix.com"; x-sender="george.dunlap@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa6.hc3370-68.iphmx.com: domain of George.Dunlap@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="George.Dunlap@citrix.com"; x-sender="George.Dunlap@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa6.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa6.hc3370-68.iphmx.com; envelope-from="George.Dunlap@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: 4cV0c0JygSlWbcJY6IEKh+PZ3xf2hH7+1DhbJNv3f7IWVMoaHRayzduwfgp7GfIor58IUj5u4q m/gZsBZXjjB5E5g1i9SX4B7qPKgWpCZXwN1KW3m12o25WavziPh2Rw7QfyvEEaTc2u/F/X5hdw YGkW/IzrTwOKpCDrp4GUwD0fdd1Fimg4MXTApNDKXIJTYfHOKava8co7soP/9Y+ZD6I0EqB4kx P+Q7GMqv0OWYQDYRCU3G3s0hfw2ObThkYRUzdresSkMV9+LehDLjAa4QdmA2pgWkuPQq14OtGj rT8= X-SBRS: 2.7 X-MesageID: 10626142 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.69,363,1571716800"; d="scan'208";a="10626142" From: George Dunlap To: Date: Fri, 27 Dec 2019 16:32:23 +0000 Message-ID: <20191227163224.4113837-8-george.dunlap@citrix.com> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191227163224.4113837-1-george.dunlap@citrix.com> References: <20191227163224.4113837-1-george.dunlap@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 8/9] RFC: golang/xenlight: Notify xenlight of SIGCHLD X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" libxl forks external processes and waits for them to complete; it therefore needs to be notified when children exit. In absence of instructions to the contrary, libxl sets up its own SIGCHLD handlers. Golang always unmasks and handles SIGCHLD itself. libxl thankfully notices this and throws an assert() rather than clobbering SIGCHLD handlers. Tell libxl that we'll be responsible for getting SIGCHLD notifications to it. Arrange for a channel in the context to receive notifications on SIGCHLD, and set up a goroutine that will pass these on to libxl. Signed-off-by: George Dunlap --- I have no idea if this is actually the right way to go about this; in particular, libxl_event.h's comment on this function refers to the comment on `libxl_childproc_reaped`, which says: * May NOT be called from within a signal handler which might * interrupt any libxl operation. The application will almost * certainly need to use the self-pipe trick (or a working pselect or * ppoll) to implement this. I don't have a good way of knowing whether the goproc-receiving-a-channel satisfies this requirement or not. It seems to work, in the sense that the pygrub process works fine. But it gets stuck a bit further on, looks like waiting for the disk; and a diff of the output between `xl create` and the golang create seems to indicate that xenstore watches aren't being delivered. Not sure if that's explicitly do to SIGCHLD, or due to some other side effect of setting libxl_sigchld_owner_mainloop, or something else entirely. CC: Nick Rosbrook --- tools/golang/xenlight/xenlight.go | 34 +++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/tools/golang/xenlight/xenlight.go b/tools/golang/xenlight/xenlight.go index e115592257..f70a4c6d96 100644 --- a/tools/golang/xenlight/xenlight.go +++ b/tools/golang/xenlight/xenlight.go @@ -33,6 +33,9 @@ import "C" import ( "fmt" + "os" + "os/signal" + "syscall" "unsafe" ) @@ -77,8 +80,23 @@ func (e Error) Error() string { // Context represents a libxl_ctx. type Context struct { - ctx *C.libxl_ctx - logger *C.xentoollog_logger_stdiostream + ctx *C.libxl_ctx + logger *C.xentoollog_logger_stdiostream + sigchld chan os.Signal +} + +// Golang always unmasks SIGCHLD, and internally has ways of +// distributing SIGCHLD to multiple recipients. libxl has provision +// for this model: just tell it when a SIGCHLD happened, and it will +// look after its own processes. +// +// This should "play nicely" with other users of SIGCHLD as long as +// they don't reap libxl's processes. +func sigchldHandler(ctx *Context) { + for _ = range ctx.sigchld { + // Can we spin up another goroutine for this? + C.libxl_childproc_sigchld_occurred(ctx.ctx) + } } // NewContext returns a new Context. @@ -93,6 +111,15 @@ func NewContext() (*Context, error) { return nil, Error(ret) } + ctx.sigchld = make(chan os.Signal, 2) + signal.Notify(ctx.sigchld, syscall.SIGCHLD) + + go sigchldHandler(&ctx) + + C.libxl_childproc_setmode(ctx.ctx, + &C.libxl_childproc_hooks{chldowner: C.libxl_sigchld_owner_mainloop}, + nil) + return &ctx, nil } @@ -102,6 +129,9 @@ func (ctx *Context) Close() error { ctx.ctx = nil C.xtl_logger_destroy((*C.xentoollog_logger)(unsafe.Pointer(ctx.logger))) + signal.Stop(ctx.sigchld) + close(ctx.sigchld) + if ret != 0 { return Error(ret) }