[openib-general] RE: Re: [PATCH] ipoib_flush_paths

Fabian Tillier ftillier at silverstorm.com
Thu Apr 6 07:00:42 PDT 2006


On 4/5/06, Sean Hefty <sean.hefty at intel.com> wrote:
> >Can't you pass in a reference to the client module for registration,
> >and then take a reference from the context of each request that is
> >released after the callback unwinds?  I thought Linux had module
> >reference functions...
>
> Yes - this is what ib_mad does.  The problem is that ib_sa, ib_addr, ib_cm, and
> soon to be ib_multicast can invoke callbacks without explicit registration /
> deregistration.  For example, the following interface has the issue:
>
> ib_do_async_operation(request, my_callback, my_context);

You don't need explicit registration/deregistration - just add a
module parameter to this function:

ib_do_async_op_safe( my_module, request, my_callback, my_context );

> I was able to come up with several possible solutions to this problem.  The
> easiest to implement is doing what Michael suggested, and calling some sort of
> wait_until_all_current_callbacks_return routine.  What I don't like about this
> approach is that the interface becomes easier to misuse (i.e. callers must
> remember to call wait_until_all_current_callbacks_return before unloading), plus
> it requires changes to interfaces that do work.

I don't like this - like you said, it's error prone.

> My preference, and it's not a very strong one at this point, is to push the
> responsibility into the module invoking the callback.  To me, that's the
> direction that the reference goes, so that's where the responsibility lies.
> Besides, it's his thread that's executing random memory as code.

Right - that module just needs to know which module to hold a reference on.

- Fab



More information about the general mailing list