Re: [PATCH rdma-next] RDMA/uverbs: Propagate errors from rdma_lookup_get_uobject()

[Leon Romanovsky <leon@kernel.org>]

On Thu, Feb 20, 2025 at 08:59:38AM +0200, Leon Romanovsky wrote:
> On Wed, Feb 19, 2025 at 01:53:35PM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 19, 2025 at 05:56:47PM +0200, Leon Romanovsky wrote:
> > > On Wed, Feb 19, 2025 at 10:46:16AM -0400, Jason Gunthorpe wrote:
> > > > On Wed, Feb 19, 2025 at 03:52:05PM +0200, Leon Romanovsky wrote:
> > > > > From: Maher Sanalla <msanalla@nvidia.com>
> > > > > 
> > > > > Currently, the IB uverbs API calls uobj_get_uobj_read(), which in turn
> > > > > uses the rdma_lookup_get_uobject() helper to retrieve user objects.
> > > > > In case of failure, uobj_get_uobj_read() returns NULL, overriding the
> > > > > error code from rdma_lookup_get_uobject(). The IB uverbs API then
> > > > > translates this NULL to -EINVAL, masking the actual error and
> > > > > complicating debugging.
> > > > 
> > > > This may have been deliberate as this old stuff is not supposed to be
> > > > returning weird error codes.
> > > 
> > > I assumed that this was the reason for such overwrite in the past, but
> > > is this continue to be true in 2025?
> > 
> > Maybe, it is ABI that leaks out libiverbs
> > 
> > But also, maybe nobody cares. There is a small chance places are
> > relying on detecting certain errnos.
> > 
> > > > What error code are you missing here?
> > > 
> > > Error returned from modify QP was masked by setting real error to be -EINVAL.
> > 
> > What errno was it though? What other errors are there that are now no
> > longer supressed?
> 
> Mainly -EBUSY from FW command interface, so users can safely call again
> to modify QP.

Forget about this comment, I was distracted, and it is -EBUSY from
uverbs_try_lock_object() and not from FW command interface.

Thanks


> 
> > 
> > I think the commit message needs a deeper analysis to be convincing
> > the ABI break is low risk
> 
> No problem, we will update commit message.
> 
> Thanks
> 
> > 
> > Jason
>