From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Bob Liu <bob.liu@oracle.com>
Cc: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xenproject.org>,
<konrad.wilk@oracle.com>
Subject: Re: [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources
Date: Wed, 27 Jul 2016 12:09:31 +0200 [thread overview]
Message-ID: <20160727100931.7hql2j4vj77q7yzp@mac> (raw)
In-Reply-To: <57987AF6.1050105@oracle.com>
On Wed, Jul 27, 2016 at 05:12:22PM +0800, Bob Liu wrote:
>
> On 07/27/2016 04:07 PM, Roger Pau Monné wrote:
> ..[snip]..
> >> @@ -2443,6 +2674,22 @@ static void blkfront_connect(struct blkfront_info *info)
> >> return;
> >> }
> >>
> >> + err = device_create_file(&info->xbdev->dev, &dev_attr_max_ring_page_order);
> >> + if (err)
> >> + goto fail;
> >> +
> >> + err = device_create_file(&info->xbdev->dev, &dev_attr_max_indirect_segs);
> >> + if (err) {
> >> + device_remove_file(&info->xbdev->dev, &dev_attr_max_ring_page_order);
> >> + goto fail;
> >> + }
> >> +
> >> + err = device_create_file(&info->xbdev->dev, &dev_attr_max_queues);
> >> + if (err) {
> >> + device_remove_file(&info->xbdev->dev, &dev_attr_max_ring_page_order);
> >> + device_remove_file(&info->xbdev->dev, &dev_attr_max_indirect_segs);
> >> + goto fail;
> >> + }
> >> xenbus_switch_state(info->xbdev, XenbusStateConnected);
> >>
> >> /* Kick pending requests. */
> >> @@ -2453,6 +2700,12 @@ static void blkfront_connect(struct blkfront_info *info)
> >> add_disk(info->gd);
> >>
> >> info->is_ready = 1;
> >> + return;
> >> +
> >> +fail:
> >> + blkif_free(info, 0);
> >> + xlvbd_release_gendisk(info);
> >> + return;
> >
> > Hm, I'm not sure whether this chunk should be in a separate patch, it seems
> > like blkfront_connect doesn't properly cleanup on error (if
> > xlvbd_alloc_gendisk fails blkif_free will not be called). Do you think you
> > could send the addition of the 'fail' label as a separate patch and fix the
> > error path of xlvbd_alloc_gendisk?
> >
>
> Sure, will fix all of your comments above.
>
> >> }
> >>
> >> /**
> >> @@ -2500,8 +2753,16 @@ static void blkback_changed(struct xenbus_device *dev,
> >> break;
> >>
> >> case XenbusStateClosed:
> >> - if (dev->state == XenbusStateClosed)
> >> + if (dev->state == XenbusStateClosed) {
> >> + if (info->reconfiguring)
> >> + if (blkfront_resume(info->xbdev)) {
> >
> > Could you please join those two conditions:
> >
> > if (info->reconfiguring && blkfront_resume(info->xbdev)) { ...
> >
> > Also, I'm not sure this is correct, if blkfront sees the "Closing" state on
> > blkback it will try to close the frontend and destroy the block device (see
> > blkfront_closing), and this should be avoided. You should call
> > blkfront_resume as soon as you see the backend move to the Closed or Closing
> > states, without calling blkfront_closing.
> >
>
> I didn't get how this can happen, backend state won't be changed to 'Closing' before blkfront_closing() is called.
> So I think current logic is fine.
I see, in dynamic_reconfig_device you change the frontend state to "Closed".
Then if the backend switches to state "Closing" blkfront will call
blkfront_closing, but that won't do anything because the frontend state is
already at the "Closed" state, at which point you just wait for the backend
to finally reach state "Closed" in order to perform the reconnection. I
stand corrected, I think the current logic is indeed fine.
Roger.
next prev parent reply other threads:[~2016-07-27 10:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 3:21 Bob Liu
2016-07-27 8:07 ` Roger Pau Monné
2016-07-27 9:12 ` Bob Liu
2016-07-27 9:29 ` [Xen-devel] " Paul Durrant
2016-07-27 10:09 ` Roger Pau Monné [this message]
2016-07-27 10:59 ` Roger Pau Monné
2016-07-27 11:21 ` Bob Liu
2016-07-27 14:24 ` Roger Pau Monné
2016-07-27 23:05 ` Bob Liu
2016-07-28 7:49 ` Roger Pau Monné
2016-07-28 9:31 ` [Xen-devel] " David Vrabel
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=20160727100931.7hql2j4vj77q7yzp@mac \
--to=roger.pau@citrix.com \
--cc=bob.liu@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®