+ peterz for scoped_cond_guard() question at the bottom
On Tue, Oct 27, 2026 at 7:24 AM Konrad Dybcio
<[email protected]> wrote:
>
> On 10/27/26 3:14 PM, Rob Clark wrote:
> > Convert (most of) the msm_gem_lock() and friends over to scope based
> > cleanup.
> >
> > Other than fixing a lock leak in msm_ioctl_gem_info_set_metadata() there
> > should be no functional change.
oh, I meant to drop the 2nd para, since it is no longer true after
rebasing on Bart's fix
> [...]
>
>
> > @@ -608,26 +600,20 @@ static int msm_ioctl_gem_info_get_metadata(struct
> > drm_gem_object *obj,
> > return 0;
> > }
> >
> > - ret = msm_gem_lock_interruptible(obj);
> > - if (ret)
> > - return ret;
>
> LLM is a bit grumpy since this no longer returns all of the return
> codes that it can but I think it doesn't matter
It is a bit odd that scoped_cond_guard() doesn't seem to have "proper"
access to the original return code.. I think I could do:
scoped_cond_guard (gem_lock_intr, return PTR_ERR(scope.lock), obj)
not sure if that is an evil hack or not?
I've added peterz, if he has an opinion
BR,
-R
> There's a couple of single-line-scopes we could shave off but any
> which way
>
> Reviewed-by: Konrad Dybcio <[email protected]>
>
> Konrad
