> 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.
Agree -- although actually in the current code, plain dev_kfree_skb() would be fine. In fact, since your patch moves the free inside a spinlock, dev_kfree_skb_irq() would be correct. > 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. I'm having a hard time understanding this race. path_free() should never be called on paths that are reachable via the list of paths or the rb-tree of paths, and unicast_send_arp() should never touch a path that is going to path_free(). Also, it seems if there is a race here then this fix is insufficient, because path_free() does a kfree() on the whole path structure, which would lead to use-after-free if unicast_send_arp() might still touch it. So could you diagram the race you are seeing? (ie what are the two different threads doing that causes a problem?) Thanks, Roland _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
