Michael S. Tsirkin wrote:
Hi! As Sean pointed out, in the existing client registration the client gets removal events even from devices which it may not be interested in.
I was actually trying to point out that a remove event may occur before a client receives a device pointer from another call.
As a way of solving this, I propose the following patch. The idea is that instead of setting client context separately with ib_set_client_data, client's add method will return ib_client_data object which is then kept in a per-device list. Returning NULL signals that the client will not be interested in this device.
I don't think that this solves the race condition that can occur between receiving a remove device event and a call, such as ib_cma_get_device(), returning a pointer to that same device.
There should be no restriction on what a client can use for their context.
In this way most ulps can now use container_of to get their context in the remove method, instead of scanning the client list each time, which in my opinion is very nice.
This seems to be a somewhat separate issue. We should be able to return a client's context with a remove event without changing the add event handling. It seems that clients should be able to read their own context and determine how to handle the remove event.
- 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
