Re: [openib-general] Re: ipoib_mcast_send.patch

2006-02-08 Thread Roland Dreier
Michael> Right, but I thought atomic test_and_set_bit implied
Michael> smp_wmb already?

So did I but then I looked in the kernel source and now I think that
set_bit operations are only ordered against other bitops that touch
the same word.  For example ia64 just uses cmpxchg to implement the
bitops, and powerpc just uses locked loads and stores.

 - R.
___
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


Re: [openib-general] Re: ipoib_mcast_send.patch

2006-01-23 Thread Michael S. Tsirkin
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Also should we count dropped packets here?

Right. And since it seems that we cant get by with just one bit,
here's the original patch again, with dropped packet counter fixed.


---

Fix the following race scenario:
Device is up.
Port event or set mcast list triggers ipoib_mcast_stop_thread,
this cancels the query and waits on mcast "done" completion.
Completion is called and "done" is set.
Meanwhile, ipoib_mcast_send arrives and starts a new query,
re-initializing "done".

Further, there's an additional issue that I saw in testing:
ipoib_mcast_send may get called when priv->broadcast is NULL
(e.g. if the device was downed and then upped internally because
of a port event).
If this happends and the sendonly join request gets completed before
priv->broadcast is set, we get an oops


Do not send multicasts if mcast thread is stopped or if
priv->broadcast is not set.

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
2006-01-23 21:24:10.0 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-23 
21:25:19.0 +0200
@@ -600,6 +600,10 @@ int ipoib_mcast_start_thread(struct net_
queue_work(ipoib_workqueue, &priv->mcast_task);
mutex_unlock(&mcast_mutex);
 
+   spin_lock_irq(&priv->lock);
+   set_bit(IPOIB_MCAST_STARTED, &priv->flags);
+   spin_unlock_irq(&priv->lock);
+
return 0;
 }
 
@@ -610,6 +614,10 @@ int ipoib_mcast_stop_thread(struct net_d
 
ipoib_dbg_mcast(priv, "stopping multicast thread\n");
 
+   spin_lock_irq(&priv->lock);
+   clear_bit(IPOIB_MCAST_STARTED, &priv->flags);
+   spin_unlock_irq(&priv->lock);
+
mutex_lock(&mcast_mutex);
clear_bit(IPOIB_MCAST_RUN, &priv->flags);
cancel_delayed_work(&priv->mcast_task);
@@ -692,6 +700,12 @@ void ipoib_mcast_send(struct net_device 
 */
spin_lock(&priv->lock);
 
+   if (!test_bit(IPOIB_MCAST_STARTED, &priv->flags) || !priv->broadcast) {
+   ++priv->stats.tx_dropped;
+   dev_kfree_skb_any(skb);
+   goto unlock;
+   }
+
mcast = __ipoib_mcast_find(dev, mgid);
if (!mcast) {
/* Let's create a new send only group now */
@@ -753,6 +767,7 @@ out:
ipoib_send(dev, skb, mcast->ah, IB_MULTICAST_QPN);
}
 
+unlock:
spin_unlock(&priv->lock);
 }
 
Index: linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- linux-2.6.15.orig/drivers/infiniband/ulp/ipoib/ipoib.h  2006-01-23 
21:24:10.0 +0200
+++ linux-2.6.15/drivers/infiniband/ulp/ipoib/ipoib.h   2006-01-23 
21:24:46.0 +0200
@@ -85,6 +85,7 @@ enum {
IPOIB_FLAG_SUBINTERFACE   = 4,
IPOIB_MCAST_RUN   = 5,
IPOIB_STOP_REAPER = 6,
+   IPOIB_MCAST_STARTED   = 7,
 
IPOIB_MAX_BACKOFF_SECONDS = 16,
 

-- 
MST
___
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


Re: [openib-general] Re: ipoib_mcast_send.patch

2006-01-17 Thread Michael S. Tsirkin
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: ipoib_mcast_send.patch
> 
> Michael> Kind of like what original patch in svn does?
> 
> Yeah -- my original question about reusing the MCAST_RUN bit was an
> honest question -- and it seems the answer is probably, "no, we need
> another bit to make it work."
> 
> It seems that killing mcast_mutex might be a good, independent cleanup.

pkey_mutex too.

-- 
MST
___
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


Re: [openib-general] Re: ipoib_mcast_send.patch

2006-01-17 Thread Roland Dreier
Michael> Kind of like what original patch in svn does?

Yeah -- my original question about reusing the MCAST_RUN bit was an
honest question -- and it seems the answer is probably, "no, we need
another bit to make it work."

It seems that killing mcast_mutex might be a good, independent cleanup.
___
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


Re: [openib-general] Re: ipoib_mcast_send.patch

2006-01-17 Thread Michael S. Tsirkin
Quoting Roland Dreier <[EMAIL PROTECTED]>:
> It seems that this code at the end of ipoib_mcast_join_task() might
> screw things up:
> 
>   ipoib_dbg_mcast(priv, "successfully joined all multicast groups\n");
> 
>   clear_bit(IPOIB_MCAST_RUN, &priv->flags);

Right. That probably was the reason I invented MCAST_STARTED.

> Probably the semantics of IPOIB_MCAST_RUN need to change slightly.
> I'm not sure this necessarily can be made to work -- maybe we just
> need more than one bit of status information to handle everything.

Kind of like what original patch in svn does?

-- 
MST
___
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