From: Roland Dreier <[EMAIL PROTECTED]> Date: Mon, 05 Jun 2006 21:57:51 -0700
> Roland> You know, looking at the ipoib code, I can't even recreate > Roland> why xmit_lock is taken in the set_multicast_list method > Roland> anyway, or how it works at all -- it seems > Roland> set_multicast_list will always be called with xmit_lock > Roland> already held. What the heck is going on? > > Never mind -- I see that the set_multicast_list work needs to be > deferred to process context, so ipoib_mcast_restart_task() doesn't run > directly from the call to set_multicast_list. > > I guess the fix in the current kernel is just something like the > below. And in the netif_tx_lock() patch, the local_irq_save() / > local_irq_restore() calls can just be removed. > > Am I on the right track? > > Anyway I won't push the patch below since the bug is harmless right > now and it can be fixed up as part of the netif_tx_lock() patch. As long as you never take priv->lock while ->xmit_lock is held your patch should be OK. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
