From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47B41C43603 for ; Mon, 9 Dec 2019 14:29:22 +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 143FD2077B for ; Mon, 9 Dec 2019 14:29:22 +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="fl04eYPV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 143FD2077B 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 1ieK22-0008O2-GH; Mon, 09 Dec 2019 14:29:02 +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 1ieK21-0008Nx-DF for xen-devel@lists.xenproject.org; Mon, 09 Dec 2019 14:29:01 +0000 X-Inumbo-ID: 3d25f020-1a90-11ea-87e3-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3d25f020-1a90-11ea-87e3-12813bfff9fa; Mon, 09 Dec 2019 14:28:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1575901740; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=X1P5ZS66O+SyV3Z0pG3ySBc5zDyuUajrOIBHrzr8Pms=; b=fl04eYPVKWuhVMu7CvBASyVQajek0n5BKT24upMvzoTpJY2h6MJluS73 2/KjOk+/g+2kaUV02sjQWthCOy3pOUnCxkBAsys0c8+O+pZrflmjpjmh3 WMkm+JG6nF7bbb1qUetNNkPPkL1AUwrlNhLK9Bx4VCRmf3mTE71V7SFXp c=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@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 (esa3.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=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: a1ru/4XWSvrJrh5euaNnkOw8Vn3o3G46oijEi/FPyzJJ5TLvObjfsKXIaMgNz5CM0IqGTp3qc5 NKJSNxeQQkbuDEB0EqCCu+3gryAHE1mLeXG3H7Dmucqllf79phmdJt0RvpKjbrz1TcKdPaV+Qa a/DvXG50rPXGHbnFS0pDCNSVnVX/hoAYQmmbAvyKX9TVwCttsWCQlnqmmrnFPoBKrSC0nQ50zH 2CANj0bjodv3B6IMfPEnJIN8sKz9KkOB1CxplML9TB/kUiwIowKQRH/nwzVmjkWuM+spastILk S4g= X-SBRS: 2.7 X-MesageID: 9395324 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.69,296,1571716800"; d="scan'208";a="9395324" Date: Mon, 9 Dec 2019 15:28:52 +0100 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: "Durrant, Paul" Message-ID: <20191209142852.GW980@Air-de-Roger> References: <20191205140123.3817-1-pdurrant@amazon.com> <20191205140123.3817-3-pdurrant@amazon.com> <20191209113926.GS980@Air-de-Roger> <19b5c2fa36b842e58bbdddd602c4e672@EX13D32EUC003.ant.amazon.com> <20191209122537.GV980@Air-de-Roger> <54e3cd3a42d8418d9a36388315deab13@EX13D32EUC003.ant.amazon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54e3cd3a42d8418d9a36388315deab13@EX13D32EUC003.ant.amazon.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL03.citrite.net (10.69.22.127) Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed 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: Juergen Gross , "xen-devel@lists.xenproject.org" , Boris Ostrovsky , Stefano Stabellini , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gTW9uLCBEZWMgMDksIDIwMTkgYXQgMTI6NDA6NDdQTSArMDAwMCwgRHVycmFudCwgUGF1bCB3 cm90ZToKPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiBGcm9tOiBSb2dlciBQYXUg TW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4KPiA+IFNlbnQ6IDA5IERlY2VtYmVyIDIwMTkg MTI6MjYKPiA+IFRvOiBEdXJyYW50LCBQYXVsIDxwZHVycmFudEBhbWF6b24uY29tPgo+ID4gQ2M6 IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0 Lm9yZzsgSnVlcmdlbgo+ID4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT47IFN0ZWZhbm8gU3RhYmVs bGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz47Cj4gPiBCb3JpcyBPc3Ryb3Zza3kgPGJvcmlz Lm9zdHJvdnNreUBvcmFjbGUuY29tPgo+ID4gU3ViamVjdDogUmU6IFtYZW4tZGV2ZWxdIFtQQVRD SCAyLzRdIHhlbmJ1czogbGltaXQgd2hlbiBzdGF0ZSBpcyBmb3JjZWQgdG8KPiA+IGNsb3NlZAo+ ID4gCj4gPiBPbiBNb24sIERlYyAwOSwgMjAxOSBhdCAxMjowMTozOFBNICswMDAwLCBEdXJyYW50 LCBQYXVsIHdyb3RlOgo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiA+ID4g RnJvbTogUm9nZXIgUGF1IE1vbm7DqSA8cm9nZXIucGF1QGNpdHJpeC5jb20+Cj4gPiA+ID4gU2Vu dDogMDkgRGVjZW1iZXIgMjAxOSAxMTozOQo+ID4gPiA+IFRvOiBEdXJyYW50LCBQYXVsIDxwZHVy cmFudEBhbWF6b24uY29tPgo+ID4gPiA+IENjOiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3Jn OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc7Cj4gPiBKdWVyZ2VuCj4gPiA+ID4gR3Jv c3MgPGpncm9zc0BzdXNlLmNvbT47IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2Vy bmVsLm9yZz47Cj4gPiA+ID4gQm9yaXMgT3N0cm92c2t5IDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xl LmNvbT4KPiA+ID4gPiBTdWJqZWN0OiBSZTogW1hlbi1kZXZlbF0gW1BBVENIIDIvNF0geGVuYnVz OiBsaW1pdCB3aGVuIHN0YXRlIGlzCj4gPiBmb3JjZWQgdG8KPiA+ID4gPiBjbG9zZWQKPiA+ID4g Pgo+ID4gPiA+IE9uIFRodSwgRGVjIDA1LCAyMDE5IGF0IDAyOjAxOjIxUE0gKzAwMDAsIFBhdWwg RHVycmFudCB3cm90ZToKPiA+ID4gPiA+IE9ubHkgZm9yY2Ugc3RhdGUgdG8gY2xvc2VkIGluIHRo ZSBjYXNlIHdoZW4gdGhlIHRvb2xzdGFjayBtYXkgbmVlZAo+ID4gdG8KPiA+ID4gPiA+IGNsZWFu IHVwLiBUaGlzIGNhbiBiZSBkZXRlY3RlZCBieSBjaGVja2luZyB3aGV0aGVyIHRoZSBzdGF0ZSBp bgo+ID4geGVuc3RvcmUKPiA+ID4gPiA+IGhhcyBiZWVuIHNldCB0byBjbG9zaW5nIHByaW9yIHRv IGRldmljZSByZW1vdmFsLgo+ID4gPiA+Cj4gPiA+ID4gSSdtIG5vdCBzdXJlIEkgc2VlIHRoZSBw b2ludCBvZiB0aGlzLCBJIHdvdWxkIGV4cGVjdCB0aGF0IGEgZmFpbHVyZSB0bwo+ID4gPiA+IHBy b2JlIG9yIHRoZSByZW1vdmFsIG9mIHRoZSBkZXZpY2Ugd291bGQgbGVhdmUgdGhlIHhlbmJ1cyBz dGF0ZSBhcwo+ID4gPiA+IGNsb3NlZCwgd2hpY2ggaXMgY29uc2lzdGVudCB3aXRoIHRoZSBhY3R1 YWwgZHJpdmVyIHN0YXRlLgo+ID4gPiA+Cj4gPiA+ID4gQ2FuIHlvdSBleHBsYWluIHdoYXQncyB0 aGUgYmVuZWZpdCBvZiBsZWF2aW5nIGEgZGV2aWNlIHdpdGhvdXQgYQo+ID4gPiA+IGRyaXZlciBp biBzdWNoIHVua25vd24gc3RhdGU/Cj4gPiA+ID4KPiA+ID4KPiA+ID4gSWYgcHJvYmUgZmFpbHMg dGhlbiBJIHRoaW5rIGl0IHNob3VsZCBsZWF2ZSB0aGUgc3RhdGUgYWxvbmUuIElmIHRoZQo+ID4g PiBzdGF0ZSBpcyBtb3ZlZCB0byBjbG9zZWQgdGhlbiBiYXNpY2FsbHkgeW91IGp1c3Qga2lsbGVk IHRoYXQKPiA+ID4gY29ubmVjdGlvbiB0byB0aGUgZ3Vlc3QgKGFzIHRoZSBmcm9udGVuZCB3aWxs IG5vcm1hbGx5IGNsb3NlIGRvd24KPiA+ID4gd2hlbiBpdCBzZWVzIHRoaXMgY2hhbmdlKSBzbywg aWYgdGhlIHByb2JlIGZhaWx1cmUgd2FzIGR1ZSB0byBhIGJ1Zwo+ID4gPiBpbiBibGtiYWNrIG9y LCBlLmcuLCBhIHRyYW5zaWVudCByZXNvdXJjZSBpc3N1ZSB0aGVuIGl0J3MgZ2FtZSBvdmVyCj4g PiA+IGFzIGZhciBhcyB0aGF0IGd1ZXN0IGdvZXMuCj4gPiAKPiA+IEJ1dCB0aGUgY29ubmVjdGlv biBjYW4gYmUgcmVzdGFydGVkIGJ5IHN3aXRjaGluZyB0aGUgYmFja2VuZCB0byB0aGUKPiA+IGlu aXQgc3RhdGUgYWdhaW4uCj4gCj4gVG9vIGxhdGUuIFRoZSBmcm9udGVuZCBzYXcgY2xvc2VkIGFu ZCB5b3UgYWxyZWFkeSBsb3N0Lgo+IAo+ID4gCj4gPiA+IFRoZSB1bHRpbWF0ZSBnb2FsIGhlcmUg aXMgUFYgYmFja2VuZCByZS1sb2FkIHRoYXQgaXMgY29tcGxldGVseQo+ID4gdHJhbnNwYXJlbnQg dG8gdGhlIGd1ZXN0LiBNb2RpZnlpbmcgYW55dGhpbmcgaW4geGVuc3RvcmUgY29tcHJvbWlzZXMg dGhhdAo+ID4gc28gd2UgbmVlZCB0byBiZSBjYXJlZnVsLgo+ID4gCj4gPiBUaGF0J3MgYSBmaW5l IGdvYWwsIGJ1dCBub3Qgc3dpdGNoaW5nIHRvIGNsb3NlZCBzdGF0ZSBpbgo+ID4geGVuYnVzX2Rl dl9yZW1vdmUgc2VlbXMgd3JvbmcsIGFzIHlvdSBoYXZlIGFjdHVhbGx5IGxlZnQgdGhlIGZyb250 ZW5kCj4gPiB3aXRob3V0IGEgbWF0Y2hpbmcgYmFja2VuZCBhbmQgd2l0aCB0aGUgc3RhdGUgbm90 IHNldCB0byBjbG9zZWQuCj4gPiAKPiAKPiBXaHkgaXMgdGhpcyBhIHByb2JsZW0/IFdpdGggdGhp cyBzZXJpZXMgZnVsbHkgYXBwbGllZCBhIChibG9jaykgYmFja2VuZCBjYW4gY29tZSBhbmQgZ28g d2l0aG91dCBuZWVkaW5nIHRvIGNoYW5nZSB0aGUgc3RhdGUuIFJlbHlpbmcgb24gZ3Vlc3RzIHRv IERUUlQgaXMgbm90IGEgc3VzdGFpbmFibGUgb3B0aW9uIGZvciBhIGNsb3VkIGRlcGxveW1lbnQu Cj4gCj4gPiBJZTogdGhhdCB3b3VsZCBiZSBmaW5lIGlmIHlvdSBleHBsaWNpdGx5IHN0YXRlIHRo aXMgaXMgc29tZSBraW5kIG9mCj4gPiBpbnRlcm5hbCBibGtiYWNrIHJlbG9hZCwgYnV0IG5vdCBm b3IgdGhlIGdlbmVyYWwgY2FzZSB3aGVyZSBibGtiYWNrCj4gPiBoYXMgYmVlbiB1bmJvdW5kLiBJ IHRoaW5rIHdlIG5lZWQgc29tZXdheSB0byBkaWZmZXJlbmNlIGEgYmxrYmFjawo+ID4gcmVsb2Fk IHZzIGEgdW5ib3VuZC4KPiA+IAo+IAo+IFdoeSBkbyB3ZSBuZWVkIHRoYXQgdGhvdWdoPyBXaHkg aXMgaXQgYWR2YW50YWdlb3VzIGZvciBhIGJhY2tlbmQgdG8gZ28gdG8gY2xvc2VkLiBObyBQViBi YWNrZW5kcyBjb3BlIHdpdGggYW4gdW5iaW5kIGFzLWlzLCBhbmQgYSB0b29sc3RhY2sgaW5pdGlh dGVkIHVucGx1ZyB3aWxsIGFsd2F5cyBzZXQgc3RhdGUgdG8gNSBhbnl3YXkuIFNvIFRCSCBhbnkg c3RhdGUgdHJhbnNpdGlvbiBkb25lIGRpcmVjdGx5IGluIHRoZSB4ZW5idXMgY29kZSBsb29rcyB3 cm9uZyB0byBtZSBhbnl3YXkgKGJ1dCBhcHBlYXJzIHRvIGJlIGEgbmVjZXNzYXJ5IGV2aWwgdG8g a2VlcCB0aGUgdG9vbHN0YWNrIHdvcmtpbmcgaW4gdGhlIGV2ZW50IGl0IHNwYXducyBhIGJhY2tl bmQgd2hlcmUgdGhlcmUgaXMgYWN0dWFsbHkgdG8gZHJpdmVyIHByZXNlbnQsIG9yIGl0IGRvZXNu J3QgY29tZSBvbmxpbmUpLgoKSU1PIHRoZSBub3JtYWwgZmxvdyBmb3IgdW5iaW5kIHdvdWxkIGJl IHRvIGF0dGVtcHQgdG8gY2xvc2Ugb3Blbgpjb25uZWN0aW9ucyBhbmQgdGhlbiByZW1vdmUgdGhl IGRyaXZlcjogbGVhdmluZyBmcm9udGVuZHMgY29ubmVjdGVkCndpdGhvdXQgYW55IGF0dGFjaGVk IGJhY2tlbmRzIGlzIG5vdCBjb3JyZWN0LCBhbmQgd2lsbCBqdXN0IGJsb2NrIHRoZQpndWVzdCBm cm9udGVuZCB1bnRpbCByZXF1ZXN0cyBzdGFydCB0aW1pbmcgb3V0LgoKSSBjYW4gc2VlIHRoZSBy ZWFzb25pbmcgZm9yIGRvaW5nIHRoYXQgZm9yIHRoZSBwdXJwb3NlIG9mIHVwZGF0aW5nIGEKYmxr YmFjayBtb2R1bGUgd2l0aG91dCBndWVzdHMgbm90aWNpbmcsIGJ1dCBJIHdvdWxkIHByZWZlciB0 aGF0CmxlYXZpbmcgY29ubmVjdGlvbnMgb3BlbiB3YXMgYW4gb3B0aW9uIHRoYXQgY291bGQgYmUg Z2l2ZW4gd2hlbgp1bmJpbmRpbmcgKG9yIG1heWJlIGEgZHJpdmVyIG9wdGlvbiBpbiBzeXNmcz8p LCBzbyB0aGF0IHRoZSBkZWZhdWx0CmJlaGF2aW91ciB3b3VsZCBiZSB0byB0cnkgdG8gY2xvc2Ug ZXZlcnl0aGluZyB3aGVuIHVuYmluZGluZyBpZgpwb3NzaWJsZS4KClRoYW5rcywgUm9nZXIuCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZwpodHRwczovL2xpc3Rz LnhlbnByb2plY3Qub3JnL21haWxtYW4vbGlzdGluZm8veGVuLWRldmVs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07872C43603 for ; Mon, 9 Dec 2019 14:29:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C3B9C2077B for ; Mon, 9 Dec 2019 14:29:00 +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="EH2gqenm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727598AbfLIO27 (ORCPT ); Mon, 9 Dec 2019 09:28:59 -0500 Received: from esa3.hc3370-68.iphmx.com ([216.71.145.155]:55955 "EHLO esa3.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727403AbfLIO27 (ORCPT ); Mon, 9 Dec 2019 09:28:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1575901739; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=X1P5ZS66O+SyV3Z0pG3ySBc5zDyuUajrOIBHrzr8Pms=; b=EH2gqenm9Iv6+PdaymFKCdHBdr1KRQJR+nXxnqIcKj1IYX3mM6G4Oa0t xgtALdDRhsCihQOgIfncGZJbNgprWRQ22QcEZAjNQ6EZrZ/+HdTvR9lwM lfTsGh5Zh/MpvoocaoJr1BcePvnig8xmgsnlmUmlnt5DoA2Dc+FblYeFG w=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@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 (esa3.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=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: a1ru/4XWSvrJrh5euaNnkOw8Vn3o3G46oijEi/FPyzJJ5TLvObjfsKXIaMgNz5CM0IqGTp3qc5 NKJSNxeQQkbuDEB0EqCCu+3gryAHE1mLeXG3H7Dmucqllf79phmdJt0RvpKjbrz1TcKdPaV+Qa a/DvXG50rPXGHbnFS0pDCNSVnVX/hoAYQmmbAvyKX9TVwCttsWCQlnqmmrnFPoBKrSC0nQ50zH 2CANj0bjodv3B6IMfPEnJIN8sKz9KkOB1CxplML9TB/kUiwIowKQRH/nwzVmjkWuM+spastILk S4g= X-SBRS: 2.7 X-MesageID: 9395324 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.69,296,1571716800"; d="scan'208";a="9395324" Date: Mon, 9 Dec 2019 15:28:52 +0100 From: Roger Pau =?iso-8859-1?Q?Monn=E9?= To: "Durrant, Paul" CC: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" , "Juergen Gross" , Stefano Stabellini , "Boris Ostrovsky" Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed Message-ID: <20191209142852.GW980@Air-de-Roger> References: <20191205140123.3817-1-pdurrant@amazon.com> <20191205140123.3817-3-pdurrant@amazon.com> <20191209113926.GS980@Air-de-Roger> <19b5c2fa36b842e58bbdddd602c4e672@EX13D32EUC003.ant.amazon.com> <20191209122537.GV980@Air-de-Roger> <54e3cd3a42d8418d9a36388315deab13@EX13D32EUC003.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54e3cd3a42d8418d9a36388315deab13@EX13D32EUC003.ant.amazon.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL03.citrite.net (10.69.22.127) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 09, 2019 at 12:40:47PM +0000, Durrant, Paul wrote: > > -----Original Message----- > > From: Roger Pau Monné > > Sent: 09 December 2019 12:26 > > To: Durrant, Paul > > Cc: linux-kernel@vger.kernel.org; xen-devel@lists.xenproject.org; Juergen > > Gross ; Stefano Stabellini ; > > Boris Ostrovsky > > Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to > > closed > > > > On Mon, Dec 09, 2019 at 12:01:38PM +0000, Durrant, Paul wrote: > > > > -----Original Message----- > > > > From: Roger Pau Monné > > > > Sent: 09 December 2019 11:39 > > > > To: Durrant, Paul > > > > Cc: linux-kernel@vger.kernel.org; xen-devel@lists.xenproject.org; > > Juergen > > > > Gross ; Stefano Stabellini ; > > > > Boris Ostrovsky > > > > Subject: Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is > > forced to > > > > closed > > > > > > > > On Thu, Dec 05, 2019 at 02:01:21PM +0000, Paul Durrant wrote: > > > > > Only force state to closed in the case when the toolstack may need > > to > > > > > clean up. This can be detected by checking whether the state in > > xenstore > > > > > has been set to closing prior to device removal. > > > > > > > > I'm not sure I see the point of this, I would expect that a failure to > > > > probe or the removal of the device would leave the xenbus state as > > > > closed, which is consistent with the actual driver state. > > > > > > > > Can you explain what's the benefit of leaving a device without a > > > > driver in such unknown state? > > > > > > > > > > If probe fails then I think it should leave the state alone. If the > > > state is moved to closed then basically you just killed that > > > connection to the guest (as the frontend will normally close down > > > when it sees this change) so, if the probe failure was due to a bug > > > in blkback or, e.g., a transient resource issue then it's game over > > > as far as that guest goes. > > > > But the connection can be restarted by switching the backend to the > > init state again. > > Too late. The frontend saw closed and you already lost. > > > > > > The ultimate goal here is PV backend re-load that is completely > > transparent to the guest. Modifying anything in xenstore compromises that > > so we need to be careful. > > > > That's a fine goal, but not switching to closed state in > > xenbus_dev_remove seems wrong, as you have actually left the frontend > > without a matching backend and with the state not set to closed. > > > > Why is this a problem? With this series fully applied a (block) backend can come and go without needing to change the state. Relying on guests to DTRT is not a sustainable option for a cloud deployment. > > > Ie: that would be fine if you explicitly state this is some kind of > > internal blkback reload, but not for the general case where blkback > > has been unbound. I think we need someway to difference a blkback > > reload vs a unbound. > > > > Why do we need that though? Why is it advantageous for a backend to go to closed. No PV backends cope with an unbind as-is, and a toolstack initiated unplug will always set state to 5 anyway. So TBH any state transition done directly in the xenbus code looks wrong to me anyway (but appears to be a necessary evil to keep the toolstack working in the event it spawns a backend where there is actually to driver present, or it doesn't come online). IMO the normal flow for unbind would be to attempt to close open connections and then remove the driver: leaving frontends connected without any attached backends is not correct, and will just block the guest frontend until requests start timing out. I can see the reasoning for doing that for the purpose of updating a blkback module without guests noticing, but I would prefer that leaving connections open was an option that could be given when unbinding (or maybe a driver option in sysfs?), so that the default behaviour would be to try to close everything when unbinding if possible. Thanks, Roger.