[openib-general] Re: RFC: revert module ref counting patches (was Re: [PATCH] ipoib_flush_paths)

[Sean Hefty]

Michael S. Tsirkin wrote:
> No, its simple: A uses C -> A does flush C at unload.
> B uses C -> B does flush C at unload.

This is C's problem.  We're forcing clients to provide the fix, which just seems 
wrong.  The issue is that A does flush C, which must wait for B's callback to 
complete.

>>For example, suppose modules A and B both call into 
>>module C, with module C performing callbacks into A and B.  For module A to 
>>unload, it is now dependent on what module B does in its callback.  
> 
> 
> This is always the case when both callbacks run form the same
> workqueue.

No - for example the IB CM uses a workqueue to invoke multiple callbacks.  When 
a client destroys their cm_id, the call blocks only while the callback 
associated with that cm_id is executing.

> I don't see how this adds dependencies that we don't already have. Witness the
> recent ib_cma/sa deadlock - without flushes.

Exactly - we hit a deadlock condition between modules where the code appeared to 
be correct.  (Although in that case, I blame the RDMA CM for making a blocking 
call in the MAD thread.)  Adding more dependencies can only lead to more issues.

- Sean