[openib-general] [PATCH] IPoIB skb panic

[Shirley Ma]

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 <xma at us.ibm.com>
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