On Sun, Sep 01, 2019 at 07:51:04PM +0300, Yuval Shaia wrote: > From: Shamir Rabinovitch <shamir.rabinovitch@xxxxxxxxxx> > > The uobject pointer will be removed from ib_x (ib_pd, ib_mr,...) objects. > uobj_get_obj_read and uobj_put_obj_read macros were constructed with the > assumption that ib_x can figure the uobject in mind. > > Fix this wrong assumption. > > Signed-off-by: Shamir Rabinovitch <shamir.rabinovitch@xxxxxxxxxx> > Signed-off-by: Shamir Rabinovitch <srabinov7@xxxxxxxxx> > --- > drivers/infiniband/core/uverbs_cmd.c | 125 ++++++++++++++++++++------- > include/rdma/uverbs_std_types.h | 8 +- > 2 files changed, 98 insertions(+), 35 deletions(-) So, after the dicussion at LPC, I think this path might be a dead end. Using refcounts makes it too easy to create situations where HW objects cannot be destroyed and there seems no easy solution. I suggest we instead use a parent/child scheme where there are no refcounts. There is only one xarray owend by the parent FD. The child FD holds a ref on the entire parent FD and maintains a list of what objects are 'imported' and what objects are 'created', however all objects always exist inside the parent xarray. Upon child destruction the 'created' list is destroyed. If for some reason those objects fail to destroy then they are sort of zombied into the parent and will be cleaned when the parent is destroyed. Applications should avoid creating conditoins where objects can be zombied. We need to modify the uobject create/destroy to know about child&parent, but I think that should just be a bit more information in the uverbs_attr_bundle Make sense? Jason
