[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Koenig, Christian <[email protected]>
> Sent: Thursday, March 12, 2026 7:34 PM
> To: SHANMUGAM, SRINIVASAN <[email protected]>;
> Deucher, Alexander <[email protected]>
> Cc: [email protected]; Dan Carpenter <[email protected]>
> Subject: Re: [PATCH] drm/amdgpu: Make amdgpu_dma_buf_attach() return paths
> consistent
>
> On 3/12/26 14:44, Srinivasan Shanmugam wrote:
> > amdgpu_dma_buf_attach() locks bo->tbo.base.resv before updating the BO
> > sharing state and unlocks it before returning.
> >
> > Return the local status variable after the unlock so the function has
> > a single consistent success return path, which avoids the Smatch
> > warning about inconsistent reservation lock handling.
>
> Mhm, that doesn't looks correct to me.
>
> >
> > Fixes the below:
> > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:111 amdgpu_dma_buf_attach()
> warn: inconsistent returns 'bo->tbo.base.resv'.
>
> As far as I can see neither that warning nor the fact that returning the
> error (which is
> always 0 at that point) would fix it makes sense to me.
>
> What exactly is going on here?
Hi Christian,
Thanks for taking a look.
My understanding was that Smatch was complaining about inconsistent lock
state tracking for bo->tbo.base.resv. The function locks the reservation
object with:
r = dma_resv_lock(bo->tbo.base.resv, NULL);
if (r)
return r;
and later unlocks it before returning:
dma_resv_unlock(bo->tbo.base.resv);
return 0;
I assumed Smatch was confused by the different return paths and suggested
returning r instead of 0 so that the function consistently returns the
same variable after the unlock
the proposed change does not actually address the reported warning.
r is always 0 after a successful dma_resv_lock(), so returning
r instead of 0 does not change the behavior.
So this looks like a Smatch false positive rather than a real issue.
I'll drop this patch.
Thanks for pointing this out.
Regards,
Srini
>
> Regards,
> Christian.
>
