Roland,
I posted the patch yesterday, it seems it only went to web site. I
repost this patch here for you to review. Please let me know if there is
any problem to apply this patch.
There are two problems in path_free(), which caused kernel skb
panic during interface up/down stress test.
1. path_free() should call dev_kfree_skb_any() (any context) instead of
dev_kfree_skb_irq() (irq context) since it is called in process
context.
2. path->queue should be protected by priv->lock since there is a race
between unicast_send_arp() and ipoib_flush_paths() to release skb when
bringing interface down. It's safe to use priv->lock, because
skb_queue_len(&path->queue) <
IPOIB_MAX_PATH_REC_QUEUE, which is 3.
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
