summary refs log tree commit diff
path: root/arch/arm/kernel/irq.c
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 /arch/arm/kernel/irq.c
parent38ec4944b593fd90c5ef42aaaa53e66ae5769d04 (diff)
downloadlinux-2afeec08ab5c86ae21952151f726bfe184f6b23d.tar.gz
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 'arch/arm/kernel/irq.c')
0 files changed, 0 insertions, 0 deletions