From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Anchal Agarwal <anchalag@amazon.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>, "hpa@zytor.com" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"jgross@suse.com" <jgross@suse.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"Kamata, Munehisa" <kamatam@amazon.com>,
"sstabellini@kernel.org" <sstabellini@kernel.org>,
"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"davem@davemloft.net" <davem@davemloft.net>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"len.brown@intel.com" <len.brown@intel.com>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"peterz@infradead.org" <peterz@infradead.org>,
"Valentin, Eduardo" <eduval@amazon.com>,
"Singh, Balbir" <sblbir@amazon.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>
Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]
Date: Wed, 17 Jun 2020 10:35:28 +0200 [thread overview]
Message-ID: <20200617083528.GW735@Air-de-Roger> (raw)
In-Reply-To: <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com>
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é wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote:
> > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> > > > + xenbus_dev_error(dev, err, "Freezing timed out;"
> > > > + "the device may become inconsistent state");
> > >
> > > Leaving the device in this state is quite bad, as it's in a closed
> > > 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 there 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 to thaw everything back intentionally is one thing I could think of.
> >
> > You can manually force this state, and then check that it will behave
> > 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.
> >
> From what I understand forcing manually is, failing the freeze without
> 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 frontend
> 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.
>
> So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail,
> I don't see it getting handled in the backend then what will be backend's state?
> Will it still switch xenbus state to 'Closed'? If not what will frontend see,
> if it tries to read backend's state through xenbus_read_driver_state ?
>
> 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?
Backend should stay in state 'Closing' then, until it can finish
tearing down.
> Frontend did not tear down the rings if backend does not switches the
> state to 'Closed' in case of failure.
>
> If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend
Backend will stay in state 'Closing' I think.
> won't be calling connect(). {From reading code in frontend_changed}
> IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus
> we did not tear down anything so calling talk_to_blkback may not be needed
>
> Does that sound correct?
I think switching to the initial state in order to try to attempt a
reconnection would be our best bet here.
Thanks, Roger.
next prev parent reply other threads:[~2020-06-17 8:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 23:33 [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Agarwal, Anchal
2020-06-04 7:05 ` Roger Pau Monné
2020-06-16 21:49 ` Anchal Agarwal
2020-06-16 22:30 ` Anchal Agarwal
2020-06-17 8:38 ` Roger Pau Monné
2020-06-17 8:35 ` Roger Pau Monné [this message]
2020-06-19 23:43 ` Anchal Agarwal
2020-06-22 8:38 ` Roger Pau Monné
2020-06-23 0:43 ` Anchal Agarwal
2020-06-23 8:19 ` Roger Pau Monné
2020-06-25 18:36 ` Anchal Agarwal
2020-06-26 9:12 ` Roger Pau Monné
2020-06-29 19:20 ` Anchal Agarwal
2020-06-30 8:30 ` Roger Pau Monné
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=20200617083528.GW735@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=anchalag@amazon.com \
--cc=axboe@kernel.dk \
--cc=benh@kernel.crashing.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=davem@davemloft.net \
--cc=dwmw@amazon.co.uk \
--cc=eduval@amazon.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=kamatam@amazon.com \
--cc=konrad.wilk@oracle.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=sblbir@amazon.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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).