[ofw] [IPoIB] [Patch] adapter could be left in INIT state.

[Alex Estrin]

Hello,

There is a possible race scenario when ipoib_port_up() called twice while adapter brings up interface.
Before each call adapter state moved to IB_PNP_PORT_INIT.
When called second time initialization is bypassed if port QP state already in transition or ready-to-send.
If second ipoib_port_up called when port initialization is done, 
it can leave adapter in state IB_PNP_PORT_INIT, which blocks port from data transmission.
Proposed patch fixes this problem.
Another minor fix included here - return status set to correct type value.

Please review.

Thanks,
Alex.

Index: kernel/ipoib_port.c
===================================================================
--- kernel/ipoib_port.c	(revision 1931)
+++ kernel/ipoib_port.c	(working copy)
@@ -5203,14 +5203,28 @@
 	IPOIB_ENTER( IPOIB_DBG_INIT );
 
 	cl_obj_lock( &p_port->obj );
-	if ((p_port->state == IB_QPS_INIT) ||
-		(p_port->state == IB_QPS_RTS)){
+	if ( p_port->state == IB_QPS_INIT ) 
+	{
 		cl_obj_unlock( &p_port->obj );
-		status = STATUS_SUCCESS;
+		status = IB_SUCCESS;
 		IPOIB_PRINT_EXIT( TRACE_LEVEL_INFORMATION, IPOIB_DBG_INIT,
 			("p_port->state = %d - Aborting.\n", p_port->state) );        
 		goto up_done;
 	}
+	else if ( p_port->state == IB_QPS_RTS )
+	{
+		cl_obj_unlock( &p_port->obj );
+		cl_obj_lock( &p_port->p_adapter->obj );
+		if( p_port->p_adapter->state == IB_PNP_PORT_INIT )
+		{
+			p_port->p_adapter->state = IB_PNP_PORT_ACTIVE;
+		}
+		cl_obj_unlock( &p_port->p_adapter->obj );
+		status = IB_SUCCESS;
+		IPOIB_PRINT_EXIT( TRACE_LEVEL_INFORMATION, IPOIB_DBG_INIT,
+			("Port init is done. p_port->state = %d.\n", p_port->state ) );
+		goto up_done;
+	}
 	p_port->state = IB_QPS_INIT;
 	cl_obj_unlock( &p_port->obj );  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipoib_adapter_state_active.patch
Type: application/octet-stream
Size: 1180 bytes
Desc: ipoib_adapter_state_active.patch
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20090205/38e875f8/attachment.obj>