On Thu, Apr 06, 2017 at 05:10:51PM +0300, Matan Barak wrote: > Effectively this kref is used to capture the dependencies between > various objects. No, that is what the usecnt is for, the kref is just to make sure we can still *access* the usecnt without derefing freed memory. > This won't solve the "inc_uobject_kref; destroy_uobject" schema, as > in this case we really want to destroy the object, but we want to > keep the uobject alive in order to get information about the > object's state at destruction. Right, this is why I said you need a destory_uobject varient that retains the kref with the caller. > If we use kref on the uobject only, we lose the kref count in ULPs. > Moreover, we'll need to somehow No, we can't really do that obviously.. I'd rather see the usecnt hoisted entirely into the uverbs layer where it can work sanely with proper locking and reserve a second for-debugging-only WARN_ON scheme in the verbs layer that checks cleanup ordering for the kapi. The kapi returning error codes on destroy is insane, I cleaned up PD at one point, but they all need fixing... Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
