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
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
