2015-06-19 12:22:29

by Imre Palik

[permalink] [raw]
Subject: [PATCH] xen-netback: fix a BUG() during initialization

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

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.

Signed-off-by: Imre Palik <[email protected]>
Cc: Matt Wilson <[email protected]>
---
drivers/net/xen-netback/xenbus.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 968787a..ec383b0 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -681,6 +681,9 @@ static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif)
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 *be)
}

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);

--
1.7.9.5


2015-06-19 15:38:23

by Wei Liu

[permalink] [raw]
Subject: Re: [PATCH] xen-netback: fix a BUG() during initialization

On Fri, Jun 19, 2015 at 02:21:51PM +0200, Imre Palik wrote:
> From: "Palik, Imre" <[email protected]>
>
> 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.
>
> Signed-off-by: Imre Palik <[email protected]>
> Cc: Matt Wilson <[email protected]>

Acked-by: Wei Liu <[email protected]>

> ---
> drivers/net/xen-netback/xenbus.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 968787a..ec383b0 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -681,6 +681,9 @@ static int xen_register_watchers(struct xenbus_device *dev, struct xenvif *vif)
> 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 *be)
> }
>
> 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);
>
> --
> 1.7.9.5

2015-06-23 10:22:56

by David Miller

[permalink] [raw]
Subject: Re: [PATCH] xen-netback: fix a BUG() during initialization

From: Imre Palik <[email protected]>
Date: Fri, 19 Jun 2015 14:21:51 +0200

> From: "Palik, Imre" <[email protected]>
>
> 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.
>
> Signed-off-by: Imre Palik <[email protected]>
> Cc: Matt Wilson <[email protected]>

Applied, thank you.