[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuHe2zkSbwyr5syK@google.com>
Date: Wed, 11 Sep 2024 11:18:03 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Jiri Kosina <jikos@...nel.org>
Cc: ". Benjamin Tissoires" <bentiss@...nel.org>,
Douglas Anderson <dianders@...omium.org>,
Hans de Goede <hdegoede@...hat.com>, Kenny Levinsen <kl@...wtf>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HID: i2c-hid: ensure various commands do not interfere
with each other
Hi Jiri,
On Wed, Sep 11, 2024 at 03:27:32PM +0200, Jiri Kosina wrote:
> On Mon, 9 Sep 2024, Dmitry Torokhov wrote:
>
> > i2c-hid uses 2 shared buffers: command and "raw" input buffer for
> > sending requests to peripherals and read data from peripherals when
> > executing variety of commands. Such commands include reading of HID
> > registers, requesting particular power mode, getting and setting
> > reports and so on. Because all such requests use the same 2 buffers
> > they should not execute simultaneously.
> >
> > Fix this by introducing "cmd_lock" mutex and acquire it whenever
> > we needs to access ihid->cmdbuf or idid->rawbuf.
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
>
> Thanks for the fix, Dmitry. Out of curiosity, did you find it by code
> inspection, or have you actually seen it happening for real, making the
> driver misbehave?
No, I have not observed this issue in the wild, that is why I di dnot
tag it explicitly for stable. It came about when I was reviewing Goodix
HID SPI driver, noticed that it was using a shared buffer, asked to and
locking, and realized that I2C HID needed the same. And just got around
to sending out the fix...
As far as I can see USB HID driver does not need it - it does not share
URBs but rather allocates new one for each request (via
usb_control_msg()).
Thanks.
--
Dmitry
Powered by blists - more mailing lists