Roland,
I found there are two problems in path_free(), it would cause kernel skb
panic.
1. path_free() should dev_kfree_skb_any() (any context) instead of
dev_kfree_skb_irq() (irq context)
2. path->queue should be protected by priv->lock since there is a
possible race between unicast_send_arp() and ipoib_flush_paths() when
bring interface down. It's safe to use priv->lock, because
skb_queue_len(&path->queue) <
IPOIB_MAX_PATH_REC_QUEUE, which is 3.
Here is the patch. Please review it and let me know if there is a
problem to apply this patch.
Signed-off-by: Shirley Ma <[EMAIL PROTECTED]>
diff -urpN infiniband/ulp/ipoib/ipoib_main.c
infiniband-skb/ulp/ipoib/ipoib_main.c
--- infiniband/ulp/ipoib/ipoib_main.c 2006-05-03 13:16:18.000000000 -0700
+++ infiniband-skb/ulp/ipoib/ipoib_main.c 2006-06-01 09:14:05.000000000
-0700
@@ -252,11 +252,11 @@ static void path_free(struct net_device
struct sk_buff *skb;
unsigned long flags;
- while ((skb = __skb_dequeue(&path->queue)))
- dev_kfree_skb_irq(skb);
-
spin_lock_irqsave(&priv->lock, flags);
+ while ((skb = __skb_dequeue(&path->queue)))
+ dev_kfree_skb_any(skb);
+
list_for_each_entry_safe(neigh, tn, &path->neigh_list, list) {
/*
* It's safe to call ipoib_put_ah() inside priv->lock
Thanks
Shirley Ma
IBM LTC
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
