[REGRESSION] thinkpad_acpi: probe deadlocks in hotkey_poll_setup() (next-20261008)

[REGRESSION] thinkpad_acpi: probe deadlocks in hotkey_poll_setup() (next-20261008)

[Oleksii Kryvenko]

From: Oleksii Kryvenko <diver.ua@gmail.com>

Hi,

On next-20261008, thinkpad_acpi hangs in probe on my ThinkPad
X9-15 Gen 1 (CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y):

  INFO: task (udev-worker):537 blocked for more than 120 seconds.
   __mutex_lock.constprop.0+0x569/0xa30
   hotkey_poll_setup+0x50/0x110 [thinkpad_acpi]
   hotkey_inputdev_open+0x36/0x50 [thinkpad_acpi]
   input_open_device+0xa7/0x170
   kbd_connect+0x73/0x90
   input_attach_handler.isra.0+0x6f/0x90
   input_register_device.cold+0xd5/0x16f
   tpacpi_pdriver_probe+0x442/0x4a0 [thinkpad_acpi]
  INFO: task (udev-worker):537 is blocked on a mutex likely owned by task (udev-worker):537.

The input core calls ->open() with dev->mutex held, and since
d6479c25ecef ("platform/x86: thinkpad_acpi: Use
input_device_enabled()") hotkey_poll_setup() takes that same mutex
again.

input_mutex stays held too, so later input devices block. The
machine hangs on shutdown, and the sound card fails to register:

  sof_sdw sof_sdw: ASoC: failed to register soundcard -4

Going back to the lockless check fixes it for me:

--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -2542,10 +2542,9 @@

 	lockdep_assert_held(&hotkey_mutex);

-	guard(mutex)(&tpacpi_inputdev->mutex);
 	if (hotkey_poll_freq > 0 &&
 	    (poll_driver_mask ||
-	     (poll_user_mask && input_device_enabled(tpacpi_inputdev)))) {
+	     (poll_user_mask && READ_ONCE(tpacpi_inputdev->users) > 0))) {
 		if (!tpacpi_hotkey_task) {
 			tpacpi_hotkey_task = kthread_run(hotkey_kthread,
 					NULL, TPACPI_NVRAM_KTHREAD_NAME);

Happy to test a proper fix.

#regzbot introduced: d6479c25ecef

Thanks,
Oleksii

Re: [REGRESSION] thinkpad_acpi: probe deadlocks in hotkey_poll_setup() (next-20261008)

[Dmitry Torokhov]

Hi Oleksii,

On Sat, Oct 10, 2026 at 03:20:24AM +0300, Oleksii Kryvenko wrote:
> On next-20261008, thinkpad_acpi hangs in probe on my ThinkPad
> X9-15 Gen 1 (CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y):
>
>   INFO: task (udev-worker):537 blocked for more than 120 seconds.
>    __mutex_lock.constprop.0+0x569/0xa30
>    hotkey_poll_setup+0x50/0x110 [thinkpad_acpi]
>    hotkey_inputdev_open+0x36/0x50 [thinkpad_acpi]
>    input_open_device+0xa7/0x170
>    kbd_connect+0x73/0x90
>    input_attach_handler.isra.0+0x6f/0x90
>    input_register_device.cold+0xd5/0x16f
>    tpacpi_pdriver_probe+0x442/0x4a0 [thinkpad_acpi]
>   INFO: task (udev-worker):537 is blocked on a mutex likely owned by task (udev-worker):537.
>
> The input core calls ->open() with dev->mutex held, and since
> d6479c25ecef ("platform/x86: thinkpad_acpi: Use
> input_device_enabled()") hotkey_poll_setup() takes that same mutex
> again.

Thanks for the report. I posted a fix for this earlier in the original
patch thread here:

https://lore.kernel.org/all/ar1iwx_390hWw_e7@google.com/

Instead of taking tpacpi_inputdev->mutex or reading dev->users directly,
it tracks whether the input device is open via a driver-local flag
protected by hotkey_mutex, which also keeps polling suppression working
properly when the device is inhibited.

I will send it out as a standalone patch shortly so it does not get lost.

Thanks.

-- 
Dmitry