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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B6197C433E1 for ; Wed, 17 Jun 2020 08:39:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7A20A2073E for ; Wed, 17 Jun 2020 08:39:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A20A2073E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 219F46B000E; Wed, 17 Jun 2020 04:39:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F00A6B0010; Wed, 17 Jun 2020 04:39:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 106766B0022; Wed, 17 Jun 2020 04:39:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id EE1046B000E for ; Wed, 17 Jun 2020 04:39:05 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BB9963571 for ; Wed, 17 Jun 2020 08:39:05 +0000 (UTC) X-FDA: 76938053850.22.skate16_270299326e06 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 97B6718038E60 for ; Wed, 17 Jun 2020 08:39:05 +0000 (UTC) X-HE-Tag: skate16_270299326e06 X-Filterd-Recvd-Size: 6788 Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 17 Jun 2020 08:39:04 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rXJCpYrqKVrAxeK/HGufl69LKC4pcQTcUUGZYB534dwGmUxVSqjN+x/504zNn9i+YPShSGKfW0 U0QMIZHnITxsotA99KOFT6OeNi8ZZ1m2L7oXIXDGt902t7cD4K5WSO+YP/COJ+vMNSTSziyGu7 HNftc9oo9lXvpx57ycrXBxaltImFbOK3Us6eexDysElhroEjtq8q7fatJV8B7YHjav9ncYU2JC 6yWJiQKYqhQurhE6bspELNnpxxK4ZszRp06jGIM0AlVuGxTyJg6YOrknOiMVmGXdVj9Ks/74SW yzE= X-SBRS: 2.7 X-MesageID: 20246153 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.73,522,1583211600"; d="scan'208";a="20246153" Date: Wed, 17 Jun 2020 10:38:50 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal CC: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200617083850.GX735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200616223003.GA28769@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20200616223003.GA28769@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-Rspamd-Queue-Id: 97B6718038E60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 16, 2020 at 10:30:03PM +0000, Anchal Agarwal wrote: > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn=C3=A9 wrote: > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > On Tue, May 19, 2020 at 11:27:50PM +0000, Anchal Agarwal wrot= e: > > > > > From: Munehisa Kamata > > > > > + xenbus_dev_error(dev, err, "Freezing timed ou= t;" > > > > > + "the device may become incon= sistent state"); > > > > > > > > Leaving the device in this state is quite bad, as it's in a c= losed > > > > state and with the queues frozen. You should make an attempt = to > > > > restore things to a working state. > > > > > > > > You mean if backend closed after timeout? Is there a way to know = that? I understand it's not good to > > > > leave it in this state however, I am still trying to find if ther= e is a good way to know if backend is still connected after timeout. > > > > Hence the message " the device may become inconsistent state". I= didn't see a timeout not even once on my end so that's why > > > > I may be looking for an alternate perspective here. may be need t= o thaw everything back intentionally is one thing I could think of. > > >=20 > > > You can manually force this state, and then check that it will beha= ve > > > correctly. I would expect that on a failure to disconnect from the > > > backend you should switch the frontend to the 'Init' state in order= to > > > try to reconnect to the backend when possible. > > >=20 > > From what I understand forcing manually is, failing the freeze withou= t > > disconnect and try to revive the connection by unfreezing the > > queues->reconnecting to backend [which never got diconnected]. May be= even > > tearing down things manually because I am not sure what state will fr= ontend > > see if backend fails to to disconnect at any point in time. I assumed= connected. > > Then again if its "CONNECTED" I may not need to tear down everything = and start > > from Initialising state because that may not work. > >=20 > > So I am not so sure about backend's state so much, lets say if xen_b= lkif_disconnect fail, > > I don't see it getting handled in the backend then what will be backe= nd's state? > > Will it still switch xenbus state to 'Closed'? If not what will front= end see,=20 > > if it tries to read backend's state through xenbus_read_driver_state = ? > >=20 > > So the flow be like: > > Front end marks XenbusStateClosing > > Backend marks its state as XenbusStateClosing > > Frontend marks XenbusStateClosed > > Backend disconnects calls xen_blkif_disconnect > > Backend fails to disconnect, the above function returns EBUSY > > What will be state of backend here?=20 > > Frontend did not tear down the rings if backend does not switc= hes the > > state to 'Closed' in case of failure. > >=20 > > If backend stays in CONNECTED state, then even if we mark it Initiali= sed in frontend, backend > > won't be calling connect(). {From reading code in frontend_changed} > > IMU, Initialising will fail since backend dev->state !=3D XenbusState= Closed plus > > we did not tear down anything so calling talk_to_blkback may not be n= eeded > >=20 > > Does that sound correct? > Send that too quickly, I also meant to add XenBusIntialised state shoul= d be ok > only if we expect backend will stay in "Connected" state. Also, I exper= imented > with that notion. I am little worried about the correctness here.=20 > Can the backend come to an Unknown state somehow? Not really, there's no such thing as an Unknown state. There are no guarantees about what a backend can do really, so it could indeed switch to a not recognized state, but that would be a bug in the backend. Roger.