From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Aurelien Chartier <aurelien.chartier@citrix.com>,
xen-devel <xen-devel@lists.xen.org>,
david.vrabel@citrix.com, ian.campbell@citrix.com
Subject: Re: [PATCH V5 2/2] xenbus: delay xenbus frontend resume if xenstored is not running
Date: Wed, 29 May 2013 11:44:59 -0400 [thread overview]
Message-ID: <20130529154459.GE23775@phenom.dumpdata.com> (raw)
In-Reply-To: <51A5C45102000078000D9751@nat28.tlf.novell.com>
On Wed, May 29, 2013 at 08:03:13AM +0100, Jan Beulich wrote:
> >>> On 28.05.13 at 19:09, Aurelien Chartier <aurelien.chartier@citrix.com> wrote:
> > If the xenbus frontend is located in a domain running xenstored, the device
> > resume is hanging because it is happening before the process resume. This
> > patch adds extra logic to the resume code to check if we are the domain
> > running xenstored and delay the resume if needed.
> >
> > Signed-off-by: Aurelien Chartier <aurelien.chartier@citrix.com>
> >
> > Changes in v2:
> > - Instead of bypassing the resume, process it in a workqueue
> > Changes in v3:
> > - Add a struct work in xenbus_device to avoid dynamic allocation
> > - Several small code fixes
> > Changes in v4:
> > - Use a dedicated workqueue
> > Changes in v5:
> > - Move create_workqueue error handling to xenbus_frontend_dev_resume
>
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> Yet nevertheless I'm still seeing room for improvement:
>
> > +static int xenbus_frontend_dev_resume(struct device *dev)
> > +{
> > + /*
> > + * If xenstored is running in this domain, we cannot access the backend
> > + * state at the moment, so we need to defer xenbus_dev_resume
> > + */
> > + if (xen_store_domain_type == XS_LOCAL) {
> > + struct xenbus_device *xdev = to_xenbus_device(dev);
> > +
> > + if (!xenbus_frontend_wq) {
> > + pr_err("%s: no workqueue to process delayed resume\n",
> > + xdev->nodename);
> > + return -EFAULT;
>
> Issuing a message here is fine, but I think you should also issue a
> pr_warn() at initialization time.
>
> > + }
> > +
> > + INIT_WORK(&xdev->work, xenbus_frontend_delayed_resume);
>
> And I also think that this would better be done once at initialization
> time too.
>
> > + queue_work(xenbus_frontend_wq, &xdev->work);
> > +
> > + return 0;
> > + }
>
> Jan
Lets do that as a follow up patch. Aurlien, I've taken your patches in.
>
next prev parent reply other threads:[~2013-05-29 15:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 17:09 [PATCH V5 0/2] xenbus: Fix S3 frontend resume when xenstored is not running Aurelien Chartier
2013-05-28 17:09 ` [PATCH V5 1/2] xenbus: save xenstore local status for later use Aurelien Chartier
2013-05-28 17:09 ` [PATCH V5 2/2] xenbus: delay xenbus frontend resume if xenstored is not running Aurelien Chartier
2013-05-29 7:03 ` Jan Beulich
2013-05-29 15:44 ` Konrad Rzeszutek Wilk [this message]
2013-05-29 16:17 ` Aurelien Chartier
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=20130529154459.GE23775@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=aurelien.chartier@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.