summaryrefslogtreecommitdiffstats
path: root/scripts/.gitignore
diff options
context:
space:
mode:
authorMichael Brown <mbrown@fensystems.co.uk>2021-04-13 16:25:12 +0100
committerDavid S. Miller <davem@davemloft.net>2021-04-13 15:24:14 -0700
commit2afeec08ab5c86ae21952151f726bfe184f6b23d (patch)
tree68d755c22e5a1ebea73397b4e1d958f88adb16a2 /scripts/.gitignore
parent38ec4944b593fd90c5ef42aaaa53e66ae5769d04 (diff)
downloadlinux-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 'scripts/.gitignore')
0 files changed, 0 insertions, 0 deletions