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@xxxxxxxxxx> > > > > > > > > > > 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 >
