Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core

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

Hi Mikhail,

On Sun, Mar 01, 2026 at 03:36:28AM +0500, Mikhail Gavrilov wrote:
> A lockdep circular locking dependency warning can be triggered
> reproducibly when using a force-feedback gamepad with uinput (for
> example, playing ELDEN RING under Wine with a Flydigi Vader 5
> controller):
> 
>   ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
> 
> The cycle is caused by four lock acquisition paths:
> 
> 1. ff upload: input_ff_upload() holds ff->mutex and calls
>    uinput_dev_upload_effect() -> uinput_request_submit() ->
>    uinput_request_send(), which acquires udev->mutex.
> 
> 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
>    uinput_create_device() -> input_register_device(), which acquires
>    input_mutex.
> 
> 3. device register: input_register_device() holds input_mutex and
>    calls kbd_connect() -> input_register_handle(), which acquires
>    dev->mutex.
> 
> 4. evdev release: evdev_release() calls input_flush_device() under
>    dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
> 
> Fix this by replacing udev->mutex with the existing
> udev->requests_lock spinlock in uinput_request_send().  The function
> only needs to atomically check device state and queue an input event
> into the ring buffer via uinput_dev_event() -- both operations are safe
> under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not
> sleep).  This breaks the ff->mutex -> udev->mutex link since a spinlock
> is a leaf in the lock ordering and cannot form cycles with mutexes.
> 
> To keep state transitions visible to uinput_request_send(), protect
> writes to udev->state in uinput_create_device() and
> uinput_destroy_device() with the same spinlock.

Thank you for the patch, it looks solid, however I wonder if creating a
separate "state_lock" spinlock would not be better than reusing
requests_lock?

Thanks.

-- 
Dmitry