On 02/06/2014 03:51 PM, Nicholas A. Bellinger wrote: > The problem with this patch and all of the other patches that follow the > same logic is the false assumption that it's safe to return from > configfs_group_operations->drop_item() before all references to the > underlying data structure containing the associated struct config_group > have been dropped. > > In this particular case, target_core_alua_drop_lu_gp() -> > config_item_put() -> target_core_alua_lu_gp_release() -> > core_alua_free_lu_gp() is still being called from ->drop_item() via > target_core_alua_lu_gp_ops->release(), so the same holds true here as > well.
Yes exactly. That's why the configfs release() doesn't free the lu_gp, it just lowers the lu_gp refcount. release() being called doesn't mean the object is going away, it just means configfs is done with it. If do_port_transition has incremented it in the meantime, the lu_gp won't be freed from the release() (because the underlying object's refcount will still be nonzero) but only when do_port_transition is done. In the normal case where there isn't a ref from do_port_transition, then it is safe to free the lu_gp from release -> put_alua_lu_gp -> release_alua_lu_gp -> kmem_cache_free. -- Andy -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
