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(+)
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);
From: Simon Wunderlich simon@open-mesh.com
When an interface is purged, the broadcast packets scheduled for this interface should get purged as well.
Signed-off-by: Simon Wunderlich simon@open-mesh.com --- send.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/send.c b/send.c index 23635bd..a7e84b2 100644 --- a/send.c +++ b/send.c @@ -598,7 +598,8 @@ batadv_purge_outstanding_packets(struct batadv_priv *bat_priv, * we delete only packets belonging to the given interface */ if ((hard_iface) && - (forw_packet->if_incoming != hard_iface)) + (forw_packet->if_incoming != hard_iface) && + (forw_packet->if_outgoing != hard_iface)) continue;
spin_unlock_bh(&bat_priv->forw_bcast_list_lock);
On Wednesday, June 24, 2015 14:50:20 Simon Wunderlich wrote:
From: Simon Wunderlich simon@open-mesh.com
When an interface is purged, the broadcast packets scheduled for this interface should get purged as well.
Signed-off-by: Simon Wunderlich simon@open-mesh.com
send.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Applied in revision 07bec2d.
Thanks, Marek
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!
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
b.a.t.m.a.n@lists.open-mesh.org