summaryrefslogtreecommitdiff
path: root/include/linux/compiler-clang.h
diff options
context:
space:
mode:
authorMichael Brown <mbrown@fensystems.co.uk>2021-04-13 16:25:12 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-04-28 12:05:47 +0200
commit35edcf73f094fc9879a3a2619ad5328ef0dfc4da (patch)
treecdeafbb4c64b718065fb2d33cb73dbb13a885f04 /include/linux/compiler-clang.h
parenta1ada6f18b294c5c367020f4419decb17cf8f59b (diff)
xen-netback: Check for hotplug-status existence before watching
[ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'include/linux/compiler-clang.h')
0 files changed, 0 insertions, 0 deletions