Hi Greg,

mið., 17. ágú. 2022 kl. 11:59 skrifaði Greg KH [off-list ref]:

On Wed, Aug 17, 2022 at 11:32:48AM +0000, Andri Yngvason wrote:

quoted

This fixes a race with the release-timer by adding acquire/release
barrier semantics.

What race?

The race is between the release timer and processing of hid input. It
is quite certain that these atomic checks are broken as is because
they're lacking memory barriers and this patch does fix an actual
problem for me.

I must admit that I don't know exactly where the execution reordering
occurs and I haven't checked the generated assembly code, but if you
look at e.g. mt_expired_timeout(), you'll see that there's nothing to
keep the compiler or CPU from hoisting the test_bit() call above the
test_and_set_bit() call.

quoted

I noticed that contacts were sometimes sticking, even with the "sticky
fingers" quirk enabled. This fixes that problem.

Cc: stable@vger.kernel.org
Signed-off-by: Andri Yngvason <redacted>
---
 drivers/hid/hid-multitouch.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 2e72922e36f5..91a4d3fc30e0 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c

@@ -1186,7 +1186,7 @@ static void mt_touch_report(struct hid_device *hid,
      int contact_count = -1;

      /* sticky fingers release in progress, abort */
-     if (test_and_set_bit(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))
+     if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))

So this is now a lock?

Why not just use a real lock instead?

I don't know. This stuff was introduced in
9609827458c37d7b2c37f2a9255631c603a5004c by Benjamin Tissoires.

Cheers,
Andri