On Sun, Jan 20, 2019 at 02:56:27PM +0200, Leon Romanovsky wrote:
> On Thu, Jan 17, 2019 at 09:11:12PM +0200, Shamir Rabinovitch wrote:
> > Now when we have the udata passed to all the ib_xxx object creation APIs
> > and the additional function 'rdma_get_ucontext' to get the ib_ucontext
> > from ib_udata stored in uverbs_attr_bundle, we can finally start to remove
> > the dependency of the drivers in the ib_xxx->uobject->context.
> >
> > Signed-off-by: Shamir Rabinovitch <shamir.rabinovitch@xxxxxxxxxx>
> > ---
[...]
> >
> > void mlx4_ib_db_unmap_user(struct mlx4_ib_ucontext *context, struct mlx4_db *db)
> > {
> > + if (WARN_ON(!context))
> > + return;
>
> I wonder, how did you come to need of those checks?
> Aren't our flows protected now and we are safe to have context != NULL?
>
> Thanks
Hi Leon,
In this specific case of the above function I think you are right and
the check is not needed. But this issue is more wide then this specific
function as Jason wrote (see below). I'll try to come up with better patch
follow what Jason said. I still have issues with drivers that store data
on the user context because as Jason said we can't assume the user
context will be available in the destroy path. So I think that for those
drivers the patch that will modify the destroy path will also modify the
create path and this information will have to find another place holder...
"
Hurm.. I think if you are going to use this API so widely then we need
to arrange for it to not fail. If udata is not null, and we are in a
driver callback with an object, then the ucontext should be guaranteed
available.
"
BR, Shamir
