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. > > 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
