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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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