Patch "xen-blkfront: don't call talk_to_blkback when already connected to blkback" has been added to the 4.6-stable tree

This is a note to let you know that I've just added the patch titled

xen-blkfront: don't call talk_to_blkback when already connected to blkback

to the 4.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
xen-blkfront-don-t-call-talk_to_blkback-when-already-connected-to-blkback.patch
and it can be found in the queue-4.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Bob Liu <[email protected]>
Date: Tue, 7 Jun 2016 10:43:15 -0400
Subject: xen-blkfront: don't call talk_to_blkback when already connected to blkback

From: Bob Liu <[email protected]>

commit efd1535270c1deb0487527bf0c3c827301a69c93 upstream.

Sometimes blkfront may twice receive blkback_changed() notification (XenbusStateConnected) after migration, which will cause talk_to_blkback() to be called twice too and confuse xen-blkback.

The flow is as follow:
blkfront blkback
blkfront_resume()

front changed()
> Connect()
> Set blkback to XenbusStateConnected

blkback_changed()

because frontstate == XenbusStateInitialised

-----
And here we get another XenbusStateConnected notification leading to:
-----
blkback_changed()

talk_to_blkback() is also called again

XenbusStateConnected to XenbusStateInitialised
(Which is not correct!)

front_changed():
> Do nothing because blkback
already in XenbusStateConnected

Now blkback is in XenbusStateConnected but blkfront is still in XenbusStateInitialised - leading to no disks.

Poking of the XenbusStateConnected state is allowed (to deal with block disk change) and has to be dealt with. The most likely cause of this bug are custom udev scripts hooking up the disks and then validating the size.

---
 drivers/block/xen-blkfront.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

@@ -2469,10 +2469,23 @@ static void blkback_changed(struct xenbu
 		break;
 
 	case XenbusStateConnected:
-		if (dev->state != XenbusStateInitialised) {
+		/*
+		 * talk_to_blkback sets state to XenbusStateInitialised
+		 * and blkfront_connect sets it to XenbusStateConnected
+		 * (if connection went OK).
+		 *
+		 * If the backend (or toolstack) decides to poke at backend
+		 * state (and re-trigger the watch by setting the state repeatedly
+		 * to XenbusStateConnected (4)) we need to deal with this.
+		 * This is allowed as this is used to communicate to the guest
+		 * that the size of disk has changed!
+		 */
+		if ((dev->state != XenbusStateInitialised) &&
+		    (dev->state != XenbusStateConnected)) {
 			if (talk_to_blkback(dev, info))
 				break;
 		}
+
 		blkfront_connect(info);
 		break;
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.6/xen-blkfront-don-t-call-talk_to_blkback-when-already-connected-to-blkback.patch queue-4.6/xen-blkfront-save-uncompleted-reqs-in-blkfront_resume.patch queue-4.6/xen-blkfront-fix-resume-issues-after-a-migration.patch