[Openib-windows] races on __destrot_obj function

Fabian Tillier ftillier at silverstorm.com
Tue Jul 11 08:15:48 PDT 2006


Hi Yossi,

On 7/11/06, Yossi Leybovich <sleybo at mellanox.co.il> wrote:
> Attached is patch that solve this problem
>
> It includes:
>
> 1. fix to cl_obj to return value if the parent port is not in
> CL_INITIALIZED

I think this should be an assertion - the client should be able to
check its state before trying to make this call - the assertion would
trap improper usage.

A state check in ipoib_port_resume should be all that's needed to
prevent the MC join from being kicked off.

> 2. fix to insert/insert_locked function to check return value

Same as above.

> 3. add ref count mechanism to help debug ref count problems

This is good.

> 4. not call port_resume in endpt cleanup but in port destroy

I think this is needed for the case where the adapter was part of an
MC group, had some sends posted, and then the MC group is being
explicitly left.  If the sends to that MC group where posted before
the MC group is resolved, they would block the send queue until some
other code path calls ipoib_port_resume.

If we check the port state in ipoib_port_resume we should be able to
leave the call to port_resume in the endpoint.

- Fab




More information about the ofw mailing list