Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Fwd: issues in ipoib
>
> > 1. pkey cache issues
> > http://thread.gmane.org/gmane.linux.drivers.openib/26684/focus=26692
>
> I thought we fixed the P_Key cache issues by correcting the oversight
> in retrying the P_Key query?
>
> > 3. ipoib race reported after code review by Eitan Rabin
> > http://openib.org/pipermail/openib-general/2006-June/022916.html
>
> Yeah, might be a problem I guess. Does it work to do
> netif_stop_queue() in ipoib_ib_dev_down()?
Hmm. Since we are lockless, could ipoib_start_xmit run even after we call
netif_stop_queue? Since interrupts are disabled anyway, can we just just take
tx_lock? How does the following look?
---
Prevent flush task from freeing the ipoib_neigh pointer,
while ipoib_start_xmit is accessing the ipoib_neigh through
the pointer is has loaded from the hardware address.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index cf71d2a..31c4b05 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -336,7 +336,8 @@ void ipoib_flush_paths(struct net_device
struct ipoib_path *path, *tp;
LIST_HEAD(remove_list);
- spin_lock_irq(&priv->lock);
+ spin_lock_irq(&priv->tx_lock);
+ spin_lock(&priv->lock);
list_splice(&priv->path_list, &remove_list);
INIT_LIST_HEAD(&priv->path_list);
@@ -352,7 +353,8 @@ void ipoib_flush_paths(struct net_device
path_free(dev, path);
spin_lock_irq(&priv->lock);
}
- spin_unlock_irq(&priv->lock);
+ spin_unlock(&priv->lock);
+ spin_unlock_irq(&priv->tx_lock);
}
static void path_rec_completion(int status,
--
MST
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
