[Openib-windows] A problem in ib_close_al

[Fabian Tillier]

Hi Leo,

On 7/19/06, Leonid Keller <leonid at mellanox.co.il> wrote:
> One more question.
> Look at __cleanup_pool_key():
>
> __cleanup_pool_key(
>        IN                              al_obj_t*
> p_obj )
> {
>        ...
>        CL_ASSERT( !p_pool_key->mad_cnt );
>        ...
>        if( p_pool_key->mad_cnt )
>        {
>                // release mad_list
>        }
> }
>
> Questions:
>        (minor) Why you expect mad_cnt=0 in ASSERT and then release the
> MADs ?

The mad_cnt should be zero in this function - the exception is if
destruction timed out and the user ignored the assertion (only in a
debug build).

>        (major) Why do we need to release MADs *here* at all?
>                ( Because if there is at least one MAD, not released to
> pool,
>                  __cleanup_pool_key() will be never called! )

I agree that all the releasing of the MADs should likely be
eliminated.  The problem is that driver verifier will complain about
memory leaks in this case, and incorrectly point at IBAL when it was
in fact the client that failed to return the MADs.  This code is just
there to clean things up as best as possible during debugging - you'll
only go through this code path in debug builds where destruction timed
out and the user proceeded past the assertion hit from the timeout.

- Fab