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

[Maher Sanalla <msanalla@nvidia.com>]

On 27/02/2025 22:57, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 03:54:13PM +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. For example, applications calling ibv_modify_qp
>> that fails with EBUSY when retrieving the QP uobject will see the
>> overridden error code EINVAL instead, masking the actual error.
> 
> I still didn't see an answer to the question of why userspace would
> hit an EBUSY down that path in a way we need to care about? That is
> doing dumb racing thread stuff that nothing should be doing..
> 
The issue isn't about whether userspace should hit EBUSY, but about 
ensuring proper error reporting when it does. While hitting EBUSY might 
result from racing threads or misuse, masking the actual error as EINVAL 
makes debugging more difficult theoretically.
Maybe this example should be removed from commit-msg?
>> Furthermore, based on rdma-core commit:
>> "2a22f1ced5f3 ("Merge pull request #1568 from jakemoroni/master")"
>> Kernel's IB uverbs return values are either ignored and passed on as is
>> to application or overridden with other errnos in a few cases.
> 
> I don't understand this sentence
> 
> Is this the defence of why it is safe to do this? But if the rdma-core
> overrides them what is the point of forwarding?
> 
> Jason
Yes. Most cases error is passed as is, only in a few cases the kernel 
error is overridden (such as alloc_dm_steering_sw_icm()).