linux-kernel - Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

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]

Date:   Wed, 21 Jun 2017 11:15:43 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Michał Kępień <kernel@...pniu.pl>,
        Rafael Wysocki <rjw@...ysocki.net>
Cc:     Jonathan Woithe <jwoithe@...t42.net>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for
 storing hotkey scancodes

On Fri, Jun 16, 2017 at 06:40:52AM +0200, Michał Kępień wrote:
> All ACPI device notify callbacks are invoked using acpi_os_execute(),
> which causes the supplied callback to be queued to a static workqueue
> which always executes on CPU 0.  This means that there is no possibility
> for any ACPI device notify callback to be concurrently executed on
> multiple CPUs, which in the case of fujitsu-laptop means that using a
> locked kfifo for handling hotkeys is redundant: as hotkey scancodes are
> only pushed and popped from within acpi_fujitsu_laptop_notify(), no risk
> of concurrent pushing and popping exists.

Was the kfifo causing a problem currently or for the migration to separate
modules? Is this purely a simplification?

Rafael, the above rationale appears sound to me. Do you have any concerns?

...

> -#define RINGBUFFERSIZE 40
>  
>  /* Debugging */
>  #define FUJLAPTOP_DBG_ERROR	  0x0001
> @@ -146,8 +144,8 @@ struct fujitsu_laptop {
>  	struct input_dev *input;
>  	char phys[32];
>  	struct platform_device *pf_device;
> -	struct kfifo fifo;
> -	spinlock_t fifo_lock;
> +	int scancode_buf[40];

Do we know why 40 was used here? A single use magic number is fine, but it would
be good to document why it is what it is if we know.

-- 
Darren Hart
VMware Open Source Technology Center