diff mbox

[maint,1/2] batman-adv: initialize up/down values when adding a gateway

Message ID 1435150220-25157-1-git-send-email-sw@simonwunderlich.de (mailing list archive)
State Accepted, archived
Commit 3c92b633715b7eca80dc7a2347e0e4dbcce1f018
Headers

Commit Message

Simon Wunderlich June 24, 2015, 12:50 p.m. UTC 
  From: Simon Wunderlich <simon@open-mesh.com>

Without this initialization, gateways which actually announce up/down
bandwidth of 0/0 could be added. If these nodes get purged later, the
gw_node structure does not get removed since batadv_gw_node_delete()
updates the gw_node with up/down bandwidth of 0/0, and the updating
function then discards the change and does not free gw_node.

This results in leaking the gw_node structures, which references other
structures: gw_node -> orig_node -> orig_node_ifinfo -> hardif. When
removing the interface later, the open reference on the hardif may cause
hangs with the infamous "unregister_netdevice: waiting for mesh1 to
become free. Usage count = 1" message.

Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
---
 gateway_client.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Antonio Quartulli June 24, 2015, 7:05 p.m. UTC | #1 
Nice catch!

On 24/06/15 14:50, Simon Wunderlich wrote:
> From: Simon Wunderlich <simon@open-mesh.com>
> 
> Without this initialization, gateways which actually announce up/down
> bandwidth of 0/0 could be added. If these nodes get purged later, the

as clarified on IRC here Simon was referring to the orig_node purge
routine (_batadv_purge_orig()) that calls batadv_gw_node_delete().

> gw_node structure does not get removed since batadv_gw_node_delete()
> updates the gw_node with up/down bandwidth of 0/0, and the updating
> function then discards the change and does not free gw_node.
> 

I have witnessed situations where nodes in the mesh receive GW TVLV
with bandwidth 0/0 even if it shouldn't be such. Therefore the situation
scenario described by Simon is more likely than what one might think.

I also think that we should investigate why we see this 0/0 announcement
when we should not. But this is for another thread ;)

> This results in leaking the gw_node structures, which references other
> structures: gw_node -> orig_node -> orig_node_ifinfo -> hardif. When
> removing the interface later, the open reference on the hardif may cause
> hangs with the infamous "unregister_netdevice: waiting for mesh1 to
> become free. Usage count = 1" message.
> 
> Signed-off-by: Simon Wunderlich <simon@open-mesh.com>

Acked-by: Antonio Quartulli <antonio@meshcoding.com>

Good job!
Marek Lindner June 28, 2015, 1:53 p.m. UTC | #2 
On Wednesday, June 24, 2015 14:50:19 Simon Wunderlich wrote:
> From: Simon Wunderlich <simon@open-mesh.com>
> 
> Without this initialization, gateways which actually announce up/down
> bandwidth of 0/0 could be added. If these nodes get purged later, the
> gw_node structure does not get removed since batadv_gw_node_delete()
> updates the gw_node with up/down bandwidth of 0/0, and the updating
> function then discards the change and does not free gw_node.
> 
> This results in leaking the gw_node structures, which references other
> structures: gw_node -> orig_node -> orig_node_ifinfo -> hardif. When
> removing the interface later, the open reference on the hardif may cause
> hangs with the infamous "unregister_netdevice: waiting for mesh1 to
> become free. Usage count = 1" message.
> 
> Signed-off-by: Simon Wunderlich <simon@open-mesh.com>
> ---
>  gateway_client.c | 2 ++
>  1 file changed, 2 insertions(+)

Applied in revision 3c92b63.

Thanks,
Marek
diff mbox

Patch

diff --git a/gateway_client.c b/gateway_client.c
index 3f32357..d8e3ead 100644
--- a/gateway_client.c
+++ b/gateway_client.c
@@ -419,6 +419,8 @@  static void batadv_gw_node_add(struct batadv_priv *bat_priv,
 
 	INIT_HLIST_NODE(&gw_node->list);
 	gw_node->orig_node = orig_node;
+	gw_node->bandwidth_down = ntohl(gateway->bandwidth_down);
+	gw_node->bandwidth_up = ntohl(gateway->bandwidth_up);
 	atomic_set(&gw_node->refcount, 1);
 
 	spin_lock_bh(&bat_priv->gw.list_lock);