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

[Alex Estrin]

Hello,

Perhaps my description of the issue wasn't clear, so here are some more details.

Adapter has a chance to stuck in IB_PNP_PORT_INIT state if PNP events arrive in following order: first IB_PNP_LID_CHANGE or IB_PNP_SM_CHANGE - ipoib_port_up() called first time, then later IB_PNP_PORT_ACTIVE - ipoib_port_up() called again.
Function will abort because port QP could be in RTS state, but it won't fix adapter state.
Please note, that race scenario is possible for both trunk and ipoib_cm branch.
If there will be no other suggestions I'll commit changes to the CM branch.

Thanks,
Alex.


> -----Original Message-----
> From: ofw-bounces at lists.openfabrics.org [mailto:ofw-bounces at lists.openfabrics.org] On Behalf Of Alex
> Estrin
> Sent: Thursday, February 05, 2009 3:00 PM
> To: ofw at lists.openfabrics.org
> Subject: [ofw] [IPoIB] [Patch] adapter could be left in INIT state.
> 
> 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/20090210/b352c49f/attachment.obj>