Re: [PATCH 1/3] tee: qcomtee: call: Fix confusing cleanup.h syntax

[Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>]

Hi,

On 12/16/2025 6:33 PM, Jens Wiklander wrote:
> Hi,
> 
> On Mon, Dec 15, 2025 at 9:30 PM Amirreza Zarrabi
> <amirreza.zarrabi@oss.qualcomm.com> wrote:
>>
>> Hi,
>>
>> On 12/12/2025 12:39 PM, Sumit Garg wrote:
>>> On Fri, Dec 12, 2025 at 02:07:40AM +0100, Krzysztof Kozlowski wrote:
>>>> On 12/12/2025 01:55, Sumit Garg wrote:
>>>>> On Mon, Dec 08, 2025 at 03:08:45AM +0100, Krzysztof Kozlowski wrote:
>>>>>> Initializing automatic __free variables to NULL without need (e.g.
>>>>>> branches with different allocations), followed by actual allocation is
>>>>>> in contrary to explicit coding rules guiding cleanup.h:
>>>>>>
>>>>>> "Given that the "__free(...) = NULL" pattern for variables defined at
>>>>>> the top of the function poses this potential interdependency problem the
>>>>>> recommendation is to always define and assign variables in one statement
>>>>>> and not group variable definitions at the top of the function when
>>>>>> __free() is used."
>>>>>>
>>>>>> Code does not have a bug, but is less readable and uses discouraged
>>>>>> coding practice, so fix that by moving declaration to the place of
>>>>>> assignment.
>>>>>
>>>>> Okay I see but..
>>>>>
>>>>>>
>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>> ---
>>>>>>  drivers/tee/qcomtee/call.c | 17 ++++++++---------
>>>>>>  1 file changed, 8 insertions(+), 9 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c
>>>>>> index 65f9140d4e1f..8f8830f0df26 100644
>>>>>> --- a/drivers/tee/qcomtee/call.c
>>>>>> +++ b/drivers/tee/qcomtee/call.c
>>>>>> @@ -395,9 +395,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx,
>>>>>>                             struct tee_ioctl_object_invoke_arg *arg,
>>>>>>                             struct tee_param *params)
>>>>>>  {
>>>>>> -  struct qcomtee_object_invoke_ctx *oic __free(kfree) = NULL;
>>>>>>    struct qcomtee_context_data *ctxdata = ctx->data;
>>>>>> -  struct qcomtee_arg *u __free(kfree) = NULL;
>>>>>>    struct qcomtee_object *object;
>>>>>>    int i, ret, result;
>>>>>>
>>>>>> @@ -412,12 +410,14 @@ static int qcomtee_object_invoke(struct tee_context *ctx,
>>>>>>    }
>>>>>>
>>>>>>    /* Otherwise, invoke a QTEE object: */
>>>>>> -  oic = qcomtee_object_invoke_ctx_alloc(ctx);
>>>>>> +  struct qcomtee_object_invoke_ctx *oic __free(kfree) =
>>>>>> +          qcomtee_object_invoke_ctx_alloc(ctx);
>>>>>>    if (!oic)
>>>>>>            return -ENOMEM;
>>>>>>
>>>>>>    /* +1 for ending QCOMTEE_ARG_TYPE_INV. */
>>>>>> -  u = kcalloc(arg->num_params + 1, sizeof(*u), GFP_KERNEL);
>>>>>> +  struct qcomtee_arg *u __free(kfree) = kcalloc(arg->num_params + 1, sizeof(*u),
>>>>>> +                                                GFP_KERNEL);
>>>>>
>>>>> ..this makes the code less readable with variable declarations floating
>>>>
>>>> Which is intentional.
>>>>
>>>>> within the function. I would rather favor to not use the cleanup.h construct
>>>>> but use explicit kfree() invocations instead like it's done in all other
>>>>> allocations in the TEE subsystem.
>>>>
>>>> Sure, fair. I just don't get why introducing cleanup.h without actually
>>>> accepting its explicitly documented style...
>>>>
>>>
>>> TBH, it is likely overlooked during review of the QTEE driver. Having a
>>> builtin warning for the undesired syntax would help the reviewers here.
>>>
>>> -Sumit
>>
>> While the style may seem unusual -- as stated in cleanup.h, using cleanup helpers
>> makes the code more readable overall compared to relying on multiple goto statements.
>> Also, it’s not just about the "__free(...) = NULL" use cases -- there are locks
>> involved as well. Switching to direct free() would require reverting those locks,
>> since mixing cleanup helpers with manual cleanup is not acceptable.
>>
>> If this behavior is explicitly documented in cleanup.h, there is no reason not
>> to use it as intended. I also support Krzysztof’s suggestion.
> 
> It looks quite ugly, and it can't be mixed with the usual goto
> cleanups (I suspect some care is needed with switch cases too), so we
> must be careful where we use it. It's not obvious that this pattern
> should be used in every function. However, where it's used, it should,
> of course, be used correctly.
> 
> Thanks for the fixes, Krzysztof.
> 
> Amir, if you're happy with the fixes, can you give your R-B for each of them?
> 
> Thanks,
> Jens

Thanks Jens.

Sorry for the late response, I was on leave ;).

I'll do.

Regards,
Amir