Patch "xen-netback: Check for hotplug-status existence before watching" has been added to the 5.11-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    xen-netback: Check for hotplug-status existence before watching

to the 5.11-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     xen-netback-check-for-hotplug-status-existence-befor.patch
and it can be found in the queue-5.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit e63c261542639273a86c49a96fba41c4c3668293
Author: Michael Brown <mbrown@xxxxxxxxxxxxxxxx>
Date:   Tue Apr 13 16:25:12 2021 +0100

    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@xxxxxxxxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul@xxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6f10e0998f1c..94d19158efc1 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -824,11 +824,15 @@ static void connect(struct backend_info *be)
 	xenvif_carrier_on(be->vif);
 
 	unregister_hotplug_status_watch(be);
-	err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch, NULL,
-				   hotplug_status_changed,
-				   "%s/%s", dev->nodename, "hotplug-status");
-	if (!err)
+	if (xenbus_exists(XBT_NIL, dev->nodename, "hotplug-status")) {
+		err = xenbus_watch_pathfmt(dev, &be->hotplug_status_watch,
+					   NULL, hotplug_status_changed,
+					   "%s/%s", dev->nodename,
+					   "hotplug-status");
+		if (err)
+			goto err;
 		be->have_hotplug_status_watch = 1;
+	}
 
 	netif_tx_wake_all_queues(be->vif->dev);
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux