linux-kernel - Re: i2c-HID: Delete unnecessary checks before the function call "gpiod

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]

Message-ID: <CAN+gG=G9xiFUDML6i44mKodW4tiQPgGQ0Ft7oV8RA1JpuuQ1KQ@mail.gmail.com>
Date:	Thu, 9 Jul 2015 16:56:34 -0400
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:	Jiri Kosina <jkosina@...e.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	linux-input <linux-input@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	kernel-janitors@...r.kernel.org,
	Julia Lawall <julia.lawall@...6.fr>
Subject: Re: i2c-HID: Delete unnecessary checks before the function call "gpiod_put"

On Thu, Jul 9, 2015 at 4:49 PM, SF Markus Elfring
<elfring@...rs.sourceforge.net> wrote:
>>>> The gpiod_put() function performs also input parameter validation
>>>> by forwarding its single input pointer to the gpiod_free() function.
>>>> Thus the test around the calls is not needed.
>>>>
>>>> This issue was detected by using the Coccinelle software.
>>>>
>>>> Signed-off-by: Markus Elfring <elfring@...rs.sourceforge.net>
>>>
>>> As Dan correctly pointed out, this is not as straightforward as it might
>>> seem on a firsr sight, because there is a WARN_ON() that might start
>>> triggering in case of !ihid->desc.
>>>
>>> Adding Benjamin. I am not applying this without his Ack.
>>>
>>
>> I think the gpiod case is the exception rather than the common rule
>> (most i2c-hid device we saw until recently were using irqs, not
>> gpios). So if I understand correctly, removing the check on ihid->desc
>> would raise a warning for most devices. This is IMO not a good thing,
>> so I would say NACK.
>>
>> Mika might have a different opinion though.
>
> The proposed update candidates are contained in the source
> file "drivers/hid/i2c-hid/i2c-hid.c" from Linux next-20150708.
>
> * i2c_hid_remove() function:
>   Can it be tolerated here that the pointer "ihid->desc" might be eventually null?
>
> * i2c_hid_probe() function:
>   Is this implementation structured in such a way that a pointer for valid data
>   will be usually passed for "ihid->desc" if the statements after the jump
>   label "err" will be reached?
>

Again, in both case it is completely normal to have "ihid->desc ==
NULL" given that this field is only retrieved in case of an ACPI
device which does not declares an IRQ but a GPIO. Most ACPI devices I
saw are using a simple IRQ, and the OF instantiations of the driver
will definitively have ihid->desc null. So I do not want to have a
warning for most of i2c-hid devices out there (because I will have to
explain that this is completely normal again and again).

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/