Re: [PATCH] liveupdate: use scoped_guard for mutex in session operations

On Mon, Aug 17 2026, Chenghao Duan wrote:

> On Fri, Aug 14, 2026 at 04:10:34PM +0200, Pratyush Yadav wrote:
>> On Fri, Aug 14 2026, Chenghao Duan wrote:
>> 
>> > Replace manually paired mutex_lock/unlock with scoped_guard to align
>> > with the coding style of the rest of the codebase and simplify locking
>> > paths.
>> 
>> No. This is done explicitly because we don't want to mix gotos with the
>> automatic cleanup-style locking. I don't think we should change this.
>> 
>
> Thank you for the clarification. I understand your concern about mixing
> `goto`-based error handling with automatic cleanup-style locking.
>
> I was wondering if these particular cases might still be suitable for
> using `scoped_guard()`. The patch only changes two manually paired mutex
> lock/unlock instances, and in both cases, the guard scope is limited to
> the operation that requires the mutex. The lock is released before the
> subsequent error-handling logic is executed, so the `goto` paths do not
> cross the scope of the guard.
>
> We could also use an explicit `scoped_guard { ... }` scope to make the
> lifetime of the guard more obvious and easier to review.
>
> Of course, I may be missing some broader considerations. If there are
> other reasons why these cases should retain the explicit lock/unlock
> pattern, I would be happy to follow your guidance.

That's one of the recommendations of the cleanup API. From
include/linux/cleanup.h:

    Lastly, given that the benefit of cleanup helpers is removal of
    "goto", and that the "goto" statement can jump between scopes, the
    expectation is that usage of "goto" and cleanup helpers is never
    mixed in the same function. I.e. for a given routine, convert all
    resources that need a "goto" cleanup to scope-based cleanup, or
    convert none of them.

Which sort of makes sense I think. Also, cleanup-style guards can cause
compilation failures too. For example, if you do:

    err = sanity_check();
    if (err)
    	goto out;
    
    guard(mutex)(&my_lock);
    
    ...

This will fail to compile.

Now this problem doesn't exist with scoped guards as far as I can tell,
but I do see why it is recommended to not mix them with gotos.

-- 
Regards,
Pratyush Yadav