On Wed, Feb 15, 2017 at 03:44:22PM +0200, Matan Barak wrote: > > static int uverbs_destroy_qp(struct ib_uobject *uobject, enum rdma_remove_reason why) > > > > Since we don't care about the reason here and it's called from the > destroy callback, > we could leave the deceleration as is. The point is to ultimately push the reason down to the driver so the driver can do the proper action. Eg force-destroy a HCA object. > I can add a WARN_ON, but this is essentially the same as ib_destroy_qp > fails when a context is destroyed (either because of hot unplug or process > termination). You won't get here because of regular destroy handler. > This is the current behavior as well. I don't think the current behavior is very good. We've had driver submissions that include random failures inside their destroy routines - the current situation is a mess. > Why should we calculate this on runtime if we could know this in compile time? Because then you need the ugly macro :) 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
