On Wed, Feb 15, 2017 at 03:45:00PM +0200, Matan Barak wrote:
> > And here I think you should move the pd->device_dealloc_pd into
> > destroy_commit by having it call what you called hot_plug, and turn
> > this simply into:
> >
> > return uobj_remove_or_put(uobj, RDMA_REMOVE_DESTROY);
> >
> > static inline int uobj_remove_or_put(struct ib_uobject *uobj, enum rdma_remove_reason why)
> > {
> > int rc = uobj->type->ops->remove(uobj, why);
> > if (!rc)
> > uverbs_uobject_put(uobj);
> >
> > /* If we are using a forced destruction mode then the driver is
> > not permitted to fail. */
> > WARN_ON(!rc && why != RDMA_REMOVE_DESTROY);
> > return rc;
> > }
> >
> > And generally use this pattern for all the destroy verbs.
> >
>
> I prefer to keep this separation. In handlers code, the handler is
> responsible to destroy the actual object and to just call
> remove_commit or lookup_put (via the accessor functions of course).
> There's a clear separation here between the uobjects management and
> the objects themselves. It's also more symmetrical - the user
> created this pd and [s]he shall destroy it.
unless the context is closed, or hot unplug is done, this argument
makes no sense.
The above is very clear and forces the needed sanity on the whole
broken destory system
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
