On Thu, Sep 06, 2018 at 06:14:21PM +0200, Roger Pau Monné wrote:
On Wed, Sep 05, 2018 at 06:27:56PM +0200, Valentin Vidic wrote:
On Wed, Sep 05, 2018 at 12:36:49PM +0200, Roger Pau Monné wrote:
On Wed, Aug 29, 2018 at 08:52:14AM +0200, Valentin Vidic wrote:
Switching to closed state earlier can cause the block-drbd script to fail with 'Device is held open by someone':
root: /etc/xen/scripts/block-drbd: remove XENBUS_PATH=backend/vbd/6/51712 kernel: [ 2222.278235] block drbd6: State change failed: Device is held open by someone kernel: [ 2222.278304] block drbd6: state = { cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate r----- } kernel: [ 2222.278340] block drbd6: wanted = { cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate r----- } root: /etc/xen/scripts/block-drbd: Writing backend/vbd/6/51712/hotplug-error /etc/xen/scripts/block-drbd failed; error detected. backend/vbd/6/51712/hotplug-status error to xenstore. root: /etc/xen/scripts/block-drbd: /etc/xen/scripts/block-drbd failed; error detected.
Signed-off-by: Valentin Vidic Valentin.Vidic@CARNet.hr Cc: stable@vger.kernel.org
drivers/block/xen-blkback/xenbus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index a4bc74e72c39..43bddc996709 100644 --- a/drivers/block/xen-blkback/xenbus.c +++ b/drivers/block/xen-blkback/xenbus.c @@ -323,6 +323,7 @@ static void xen_blkif_free(struct xen_blkif *blkif) { WARN_ON(xen_blkif_disconnect(blkif)); xen_vbd_free(&blkif->vbd);
- xenbus_switch_state(blkif->be->dev, XenbusStateClosed); kfree(blkif->be->mode); kfree(blkif->be);
@@ -814,7 +815,6 @@ static void frontend_changed(struct xenbus_device *dev, case XenbusStateClosed: xen_blkif_disconnect(be->blkif);
xenbus_switch_state(dev, XenbusStateClosed);AFAICT, this will cause the backend to never switch to 'Closed' state until the toolstack sets online to 0, which is not good IMO.
If for example a frontend decides to close a device, the backend will stay in state 'Closing' until the toolstack actually removes the disk by setting online to 0.
This will prevent resetting blk connections, as blkback will refuse to switch to state XenbusStateInitWait unless it's at XenbusStateClosed (see the XenbusStateInitialising case in frontend_changed), which will never be reached with your patch.
Ok, is it possible to test this somehow?
Yes, you can try booting a PV guest with pvgrub, that will cause pvgrub to open a blk connection, then close it and afterwards the OS kernel will start a new connection.
Indeed the boot hangs after pvgrub loads the kernel and initrd, so it seems this does not work as expected.