On Thu, Mar 07, 2019 at 08:57:36AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 26, 2019 at 02:44:53PM +0200, Shamir Rabinovitch wrote:
> > @@ -969,7 +943,8 @@ EXPORT_SYMBOL(uverbs_fd_class);
> > struct ib_uobject *
> > uverbs_get_uobject_from_file(u16 object_id,
> > struct ib_uverbs_file *ufile,
> > - enum uverbs_obj_access access, s64 id)
> > + enum uverbs_obj_access access, s64 id,
> > + struct uverbs_attr_bundle *attrs)
> > {
>
> Don't pass ufile and attrs in the same parameter list. Replace the
> ufile with attrs->ufile. Several cases of this
OK.
>
> > + rdma_lookup_get_uobject(uobj_get_type(_attrs, _type), (_attrs)->ufile, \
> > + _uobj_check_id(_id), UVERBS_LOOKUP_READ, _attrs)
> > +/*
> > + * NOTE: no need to pass _attrs down to rdma_lookup_get_uobject here because
> > + * rdma_lookup_get_uobject is only used to set the ucontext for idr uobjects...
> > + */
> > #define ufd_get_read(_type, _fdnum, _attrs) \
> > rdma_lookup_get_uobject(uobj_get_type(_attrs, _type), (_attrs)->ufile, \
> > (_fdnum)*typecheck(s32, _fdnum), \
> > - UVERBS_LOOKUP_READ)
> > + UVERBS_LOOKUP_READ, NULL)
>
> ?? fd's have ubojects too, why wouldn't we pass the attrs??
Are those uobjects point to ib_x objects that are owned by the driver
layer? I thought no... The only intention with the atts here is to copy
the ucontext from the uobject to the attrs and later send this context to
the driver layer inside attrs.
>
> Jason
