Roland> Crazy idea: can we just get away with never clearing
Roland> ops->destructor? ipoib_neigh_destructor() checks if the
Roland> neighbour structure has an IPoIB structure attached and
Roland> does nothing if it doesn't. So does it hurt to leave
Roland> ops->destructor set to ipoib_neigh_destructor() forever?
ie just do the following...
(It seems to me that if this approach has a problem, we're leaking
IPoIB neighbour structures already...)
--- infiniband/ulp/ipoib/ipoib_main.c (revision 4929)
+++ infiniband/ulp/ipoib/ipoib_main.c (working copy)
@@ -247,7 +247,6 @@ static void path_free(struct net_device
if (neigh->ah)
ipoib_put_ah(neigh->ah);
*to_ipoib_neigh(neigh->neighbour) = NULL;
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
}
@@ -530,7 +529,6 @@ static void neigh_add_path(struct sk_buf
err:
*to_ipoib_neigh(skb->dst->neighbour) = NULL;
list_del(&neigh->list);
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
++priv->stats.tx_dropped;
--- infiniband/ulp/ipoib/ipoib_multicast.c (revision 4936)
+++ infiniband/ulp/ipoib/ipoib_multicast.c (working copy)
@@ -114,7 +114,6 @@ static void ipoib_mcast_free(struct ipoi
if (neigh->ah)
ipoib_put_ah(neigh->ah);
*to_ipoib_neigh(neigh->neighbour) = NULL;
- neigh->neighbour->ops->destructor = NULL;
kfree(neigh);
}
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
