linux-kernel - Re: [PATCH v2] HID: Replace semaphore 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK8P3a03nW5wVX3zZpN9xj5D=0omfeewD9jG=EjU-1_V9b5WvA@mail.gmail.com>
Date:   Tue, 13 Jun 2017 22:00:44 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Binoy Jayan <binoy.jayan@...aro.org>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-input@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rajendra <rnayak@...eaurora.org>,
        Mark Brown <broonie@...nel.org>,
        Jiri Kosina <jikos@...nel.org>,
        David Herrmann <dh.herrmann@...glemail.com>,
        Andrew de los Reyes <adlr@...omium.org>
Subject: Re: [PATCH v2] HID: Replace semaphore driver_lock with mutex

On Tue, Jun 13, 2017 at 12:09 PM, Binoy Jayan <binoy.jayan@...aro.org> wrote:
> Hi,
>
> On 13 June 2017 at 15:26, Benjamin Tissoires
> <benjamin.tissoires@...hat.com> wrote:
>
>>> Looks good to me, but I see you didn't include David and Andrew on
>>> Cc, it would be good for at least one of them to provide an Ack as well.
>>
>> Please also CC linux-input@
>
> Will do that.
>> (one more nitpick below too)
>> A little bit below, there is:
>>         bool io_started;                                                /* Protected by driver_lock. If IO has started */
>>
>> You should probably remove the mention to driver_lock here.
>
> Will remove the reference too.
>
> Thank you for noticing that, initially I missed it as I thought
> 'io_started' somehow
> influences the increment of the semaphore, but its anyway used only in
> hid-core.c

It is also used in hid_device_io_start()  and hid_device_io_stop(), but
what's important here is that these are only ever called from inside of
hid_device_probe() and other functions called by that, so no
synchronization across CPUs is required here.

I think in theory, it could be accessed from below hid_device_remove
as well, but I did not find any instance of that.

        Arnd