linux-kernel - Re: [PATCH 2/2] Input: add Himax HX852x(ES) touchscreen driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 Sep 2023 19:58:25 +0200
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     stephan@...hold.net, Jeff LaBundy <jeff@...undy.com>
Cc:     conor+dt@...nel.org, devicetree@...r.kernel.org,
        dmitry.torokhov@...il.com, jonathan.albrieux@...il.com,
        krzysztof.kozlowski+dt@...aro.org, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        rydberg@...math.org
Subject: Re: [PATCH 2/2] Input: add Himax HX852x(ES) touchscreen driver

Le 17/09/2023 à 18:37, Jeff LaBundy a écrit :

>>> +	error = input_register_device(hx->input_dev);
>>> +	if (error) {
>>
>> input_mt_destroy_slots() should be called here, or in an error handling path
>> below, or via a devm_add_action_or_reset().
> 
> This seems like a memory leak in every touchscreen driver; maybe it is more
> practical to have the input core handle this clean-up.
> 
> Other drivers can and do insert other return paths between input_mt_init_slots()
> and input_register_device(), so it seems that we cannot solve this by calling
> input_mt_destroy_slots() from the error path within input_register_device().
> 
> Maybe a better option is to update input_mt_init_slots() to use device-managed
> allocation instead?

I think that devm_ is the way to go:

    $ git grep input_mt_init_slots | wc -l
    82

    $ git grep input_mt_destroy_slots | wc -l
    6

I'll send a patch for it.

> 
>>
>> It should also be called in a .remove function (unless
>> devm_add_action_or_reset is prefered)
> 
> I think the remove path is OK, as input_dev_release() handles this for us. In
> case I have misunderstood, please let me know.

Agreed. I missed that.

CJ