diff options
author | Michael Brown <mbrown@fensystems.co.uk> | 2021-04-13 16:25:12 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2021-04-13 15:24:14 -0700 |
commit | 2afeec08ab5c86ae21952151f726bfe184f6b23d (patch) | |
tree | 68d755c22e5a1ebea73397b4e1d958f88adb16a2 /fs/coda | |
parent | 38ec4944b593fd90c5ef42aaaa53e66ae5769d04 (diff) | |
download | linux-2afeec08ab5c86ae21952151f726bfe184f6b23d.tar.bz2 |
xen-netback: Check for hotplug-status existence before watching
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect: xenstore does allow a watch to
be registered for a nonexistent node (and will send notifications
should the node be subsequently created).
As of commit 1f2565780 ("xen-netback: remove 'hotplug-status' once it
has served its purpose"), this leads to a failure when a domU
transitions into XenbusStateConnected more than once. On the first
domU transition into Connected state, the "hotplug-status" node will
be deleted by the hotplug_status_changed() callback in dom0. On the
second or subsequent domU transition into Connected state, the
hotplug_status_changed() callback will therefore never be invoked, and
so the backend will remain stuck in InitWait.
This failure prevents scenarios such as reloading the xen-netfront
module within a domU, or booting a domU via iPXE. There is
unfortunately no way for the domU to work around this dom0 bug.
Fix by explicitly checking for existence of the "hotplug-status" node,
thereby creating the behaviour that was previously assumed to exist.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'fs/coda')
0 files changed, 0 insertions, 0 deletions