Patch "xen-netback: fix a BUG() during initialization" has been added to the 4.1-stable tree

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

xen-netback: fix a BUG() during initialization

to the 4.1-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-fix-a-bug-during-initialization.patch
and it can be found in the queue-4.1 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: "Palik, Imre" <[email protected]>
Date: Fri, 19 Jun 2015 14:21:51 +0200
Subject: xen-netback: fix a BUG() during initialization

From: "Palik, Imre" <[email protected]>

[ Upstream commit 12b322ac85208de564ecf23aa754d796a91de21f ]

Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime settable") introduced the capability to change the bandwidth rate limit at runtime. But it also introduced a possible crashing bug.

If netback receives two XenbusStateConnected without getting the hotplug-status watch firing in between, then it will try to register the watches for the rate limiter again. But this triggers a BUG() in the watch registration code.

The fix modifies connect() to remove the possibly existing packet-rate watches before trying to install those watches. This behaviour is in line with how connect() deals with the hotplug-status watch.

---
 drivers/net/xen-netback/xenbus.c |    4 ++++
 1 file changed, 4 insertions(+)

@@ -681,6 +681,9 @@ static int xen_register_watchers(struct
 	char *node;
 	unsigned maxlen = strlen(dev->nodename) + sizeof("/rate");
 
+	if (vif->credit_watch.node)
+		return -EADDRINUSE;
+
 	node = kmalloc(maxlen, GFP_KERNEL);
 	if (!node)
 		return -ENOMEM;

@@ -770,6 +773,7 @@ static void connect(struct backend_info
 	}
 
 	xen_net_read_rate(dev, &credit_bytes, &credit_usec);
+	xen_unregister_watchers(be->vif);
 	xen_register_watchers(dev, be->vif);
 	read_xenbus_vif_flags(be);
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.1/xen-netback-fix-a-bug-during-initialization.patch