mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-10-29 23:53:32 +00:00
xen-blkfront: don't call talk_to_blkback when already connected to blkback
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() > talk_to_blkback() > Set blkfront to XenbusStateInitialised front changed() > Connect() > Set blkback to XenbusStateConnected blkback_changed() > Skip talk_to_blkback() because frontstate == XenbusStateInitialised > blkfront_connect() > Set blkfront to XenbusStateConnected ----- And here we get another XenbusStateConnected notification leading to: ----- blkback_changed() > because now frontstate != XenbusStateInitialised talk_to_blkback() is also called again > blkfront state changed from 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. Signed-off-by: Bob Liu <bob.liu@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This commit is contained in:
parent
116f7d4a21
commit
efd1535270
1 changed files with 14 additions and 1 deletions
|
@ -2485,10 +2485,23 @@ static void blkback_changed(struct xenbus_device *dev,
|
||||||
break;
|
break;
|
||||||
|
|
||||||
case XenbusStateConnected:
|
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))
|
if (talk_to_blkback(dev, info))
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
|
|
||||||
blkfront_connect(info);
|
blkfront_connect(info);
|
||||||
break;
|
break;
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue