[ofw] [patch][IPoIB_NDIS6_CM] Take a send lock when join_mcast_group is not called directly from a send path
Alex Naslednikov
xalex at mellanox.co.il
Sun May 22 04:45:51 PDT 2011
Done at 3116
From: Smith, Stan [mailto:stan.smith at intel.com]
Sent: Thursday, May 19, 2011 10:42 PM
To: Alex Naslednikov; ofw at lists.openfabrics.org
Subject: RE: [ofw] [patch][IPoIB_NDIS6_CM] Take a send lock when join_mcast_group is not called directly from a send path
Patch tests OK; no negative impact on UD or CM flows.
Looks good to me.
stan.
From: Alex Naslednikov [mailto:xalex at mellanox.co.il]
Sent: Thursday, May 19, 2011 8:39 AM
To: Smith, Stan; ofw at lists.openfabrics.org
Subject: RE: [ofw] [patch][IPoIB_NDIS6_CM] Take a send lock when join_mcast_group is not called directly from a send path
Hello Stan,
Yes, this patch is different and running regression since April, 28.
CM flow wasn't tested separately
From: Smith, Stan [mailto:stan.smith at intel.com]
Sent: Tuesday, May 17, 2011 12:01 AM
To: Alex Naslednikov; ofw at lists.openfabrics.org
Subject: RE: [ofw] [patch][IPoIB_NDIS6_CM] Take a send lock when join_mcast_group is not called directly from a send path
Hello,
This locking patch reminds me of an earlier version which dead locked due to the routine being called from two different locations :
One call site required locking send_lock, while the other call site already held the send_lock, hence the dead lock....
Is this patch different?
How much IPoIB_CM testing has been accomplished with this patch installed?
thanks,
stan.
From: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Alex Naslednikov
Sent: Thursday, April 28, 2011 2:44 AM
To: ofw at lists.openfabrics.org
Subject: [ofw] [patch][IPoIB_NDIS6_CM] Take a send lock when join_mcast_group is not called directly from a send path
Function ipoib_endpt_queue requires send lock to be held.
ipoib_port_join_mcast calls to __endpt_mgr_ref that calls to ipoib_endpt_queue , but ipoib_port_join_mcast isn't always send lock protected.
Signed off by: Alexander Naslednikov (xalex at mellanox.co.il)
Index: B:/users/xalex/MLNX_VPI_trunk/ulp/ipoib_NDIS6_CM/kernel/ipoib_adapter.cpp
===================================================================
--- B:/users/xalex/MLNX_VPI_trunk/ulp/ipoib_NDIS6_CM/kernel/ipoib_adapter.cpp (revision 7799)
+++ B:/users/xalex/MLNX_VPI_trunk/ulp/ipoib_NDIS6_CM/kernel/ipoib_adapter.cpp (revision 7800)
@@ -987,6 +987,8 @@
}
/* Add new entries */
+ /* The lock is important here cause ipoib_endpt_queue will be called later and it requires lock to be held */
+ cl_spinlock_acquire( &p_port->send_lock );
for( i = 0; i < num_macs; i++ )
{
for( j = 0; j < p_adapter->mcast_array_size; j++ )
@@ -1009,6 +1011,7 @@
ipoib_port_join_mcast( p_port, p_mac_array[i], IB_MC_REC_STATE_FULL_MEMBER );
}
}
+ cl_spinlock_release( &p_port->send_lock );
}
/* Copy the MAC array. */
@@ -1316,6 +1319,8 @@
}
}
/* Join all programmed multicast groups. */
+ /* The lock is important here cause ipoib_endpt_queue will be called later and it requires lock to be held */
+ cl_spinlock_acquire( &p_adapter->p_port->send_lock );
for( i = 0; i < p_adapter->mcast_array_size; i++ )
{
IPOIB_PRINT_EXIT( TRACE_LEVEL_INFORMATION, IPOIB_DBG_MCAST,
@@ -1324,7 +1329,8 @@
p_adapter->mcast_array[i],
IB_MC_REC_STATE_FULL_MEMBER );
}
-
+ cl_spinlock_release( &p_adapter->p_port->send_lock );
+
/* Register all existing addresses. */
ipoib_reg_addrs( p_adapter );
Alexander (XaleX) Naslednikov
SW Networking Team
Mellanox Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20110522/5ebc2d4e/attachment.html>
More information about the ofw
mailing list