[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