Message-ID: <CABXGCsMoxag+kEwHhb7KqhuyxfmGGd0P=tHZyb1uKE0pLr8Hkg@mail.gmail.com>
Date: Tue, 16 Dec 2025 02:40:38 +0500
From: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
To: linux-input@...r.kernel.org, 
	Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: [BUG] lockdep: circular locking dependency in uinput/input_ff under
 Wine (ELDEN RING, gamepad)

Hello,

I would like to report a reproducible lockdep warning in the input subsystem,
involving uinput and force-feedback handling.

After connecting a gamepad (Flydigi Vader 5) and playing ELDEN RING under Wine,
the kernel consistently reports a possible circular locking dependency
within approximately 5 minutes of gameplay.

This issue reproduces 100% of the time on my system.

Steps to reproduce:
- Boot a kernel with CONFIG_LOCKDEP enabled
- Connect a USB gamepad
- Start Wine
- Launch ELDEN RING
- Play for approximately 5 minutes

The kernel emits the following warning:
[ 4151.300019] ======================================================
[ 4151.300023] WARNING: possible circular locking dependency detected
[ 4151.300027] 6.19.0-rc1-dirty #31 Tainted: G     U
[ 4151.300031] ------------------------------------------------------
[ 4151.300034] winedevice.exe/50772 is trying to acquire lock:
[ 4151.300038] ffff8888da59b878 (&newdev->mutex){+.+.}-{4:4}, at:
uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300057]
               but task is already holding lock:
[ 4151.300060] ffff8888c46040b8 (&ff->mutex){+.+.}-{4:4}, at:
input_ff_upload+0x160/0xd70
[ 4151.300075]
               which lock already depends on the new lock.

[ 4151.300078]
               the existing dependency chain (in reverse order) is:
[ 4151.300081]
               -> #2 (&ff->mutex){+.+.}-{4:4}:
[ 4151.300091]        __lock_acquire+0x56a/0xbd0
[ 4151.300099]        lock_acquire.part.0+0xc7/0x270
[ 4151.300105]        __mutex_lock+0x1b0/0x2290
[ 4151.300111]        input_ff_flush+0x56/0x150
[ 4151.300116]        input_flush_device+0x91/0xf0
[ 4151.300122]        evdev_release+0x2cb/0x3a0
[ 4151.300126]        __fput+0x36e/0xac0
[ 4151.300132]        fput_close_sync+0xde/0x1b0
[ 4151.300137]        __x64_sys_close+0x7d/0xd0
[ 4151.300142]        do_syscall_64+0x9c/0x4e0
[ 4151.300148]        entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300153]
               -> #1 (&dev->mutex#2){+.+.}-{4:4}:
[ 4151.300164]        __lock_acquire+0x56a/0xbd0
[ 4151.300170]        lock_acquire.part.0+0xc7/0x270
[ 4151.300175]        __mutex_lock+0x1b0/0x2290
[ 4151.300179]        __input_unregister_device+0x20/0x480
[ 4151.300183]        input_unregister_device+0x88/0xc0
[ 4151.300188]        uinput_destroy_device+0x19e/0x210 [uinput]
[ 4151.300193]        uinput_ioctl_handler.isra.0+0x2b5/0x1170 [uinput]
[ 4151.300198]        __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300204]        do_syscall_64+0x9c/0x4e0
[ 4151.300210]        entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300215]
               -> #0 (&newdev->mutex){+.+.}-{4:4}:
[ 4151.300221]        check_prev_add+0xe1/0xca0
[ 4151.300225]        validate_chain+0x4cb/0x730
[ 4151.300228]        __lock_acquire+0x56a/0xbd0
[ 4151.300231]        lock_acquire.part.0+0xc7/0x270
[ 4151.300235]        __mutex_lock+0x1b0/0x2290
[ 4151.300237]        uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300241]        uinput_dev_upload_effect+0x123/0x1c1 [uinput]
[ 4151.300244]        input_ff_upload+0x269/0xd70
[ 4151.300247]        evdev_do_ioctl+0xce6/0x14f0
[ 4151.300249]        evdev_ioctl+0x12a/0x160
[ 4151.300252]        __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300255]        do_syscall_64+0x9c/0x4e0
[ 4151.300258]        entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300261]
               other info that might help us debug this:

[ 4151.300262] Chain exists of:
                 &newdev->mutex --> &dev->mutex#2 --> &ff->mutex

[ 4151.300270]  Possible unsafe locking scenario:

[ 4151.300272]        CPU0                    CPU1
[ 4151.300274]        ----                    ----
[ 4151.300275]   lock(&ff->mutex);
[ 4151.300279]                                lock(&dev->mutex#2);
[ 4151.300283]                                lock(&ff->mutex);
[ 4151.300286]   lock(&newdev->mutex);
[ 4151.300289]
                *** DEADLOCK ***

[ 4151.300291] 2 locks held by winedevice.exe/50772:
[ 4151.300294]  #0: ffff888153d93128 (&evdev->mutex){+.+.}-{4:4}, at:
evdev_ioctl+0x76/0x160
[ 4151.300301]  #1: ffff8888c46040b8 (&ff->mutex){+.+.}-{4:4}, at:
input_ff_upload+0x160/0xd70
[ 4151.300309]
               stack backtrace:
[ 4151.300312] CPU: 14 UID: 1000 PID: 50772 Comm: winedevice.exe
Tainted: G     U              6.19.0-rc1-dirty #31 PREEMPT(lazy)
[ 4151.300316] Tainted: [U]=USER
[ 4151.300317] Hardware name: ASUS System Product Name/ROG STRIX
B650E-I GAMING WIFI, BIOS 3263 06/09/2025
[ 4151.300319] Call Trace:
[ 4151.300320]  <TASK>
[ 4151.300323]  dump_stack_lvl+0x84/0xd0
[ 4151.300328]  print_circular_bug.cold+0x38/0x46
[ 4151.300332]  check_noncircular+0x148/0x170
[ 4151.300336]  check_prev_add+0xe1/0xca0
[ 4151.300340]  validate_chain+0x4cb/0x730
[ 4151.300343]  __lock_acquire+0x56a/0xbd0
[ 4151.300347]  lock_acquire.part.0+0xc7/0x270
[ 4151.300349]  ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300352]  ? rcu_is_watching+0x15/0xe0
[ 4151.300356]  ? __pfx___might_resched+0x10/0x10
[ 4151.300359]  ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300361]  ? lock_acquire+0xf6/0x130
[ 4151.300364]  __mutex_lock+0x1b0/0x2290
[ 4151.300366]  ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300371]  ? find_held_lock+0x2b/0x80
[ 4151.300375]  ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300378]  ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300381]  ? __pfx___mutex_lock+0x10/0x10
[ 4151.300384]  ? do_raw_spin_unlock+0x59/0x230
[ 4151.300386]  ? uinput_request_reserve_slot+0x342/0x4c0 [uinput]
[ 4151.300388]  ? uinput_request_reserve_slot+0x342/0x4c0 [uinput]
[ 4151.300391]  ? __pfx_uinput_request_reserve_slot+0x10/0x10 [uinput]
[ 4151.300394]  ? rcu_is_watching+0x15/0xe0
[ 4151.300397]  ? uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300399]  uinput_request_submit.part.0+0x25/0x2a0 [uinput]
[ 4151.300402]  uinput_dev_upload_effect+0x123/0x1c1 [uinput]
[ 4151.300407]  ? __pfx_uinput_dev_upload_effect+0x10/0x10 [uinput]
[ 4151.300411]  ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300414]  input_ff_upload+0x269/0xd70
[ 4151.300418]  evdev_do_ioctl+0xce6/0x14f0
[ 4151.300420]  ? evdev_ioctl+0x76/0x160
[ 4151.300422]  ? __pfx_evdev_do_ioctl+0x10/0x10
[ 4151.300425]  ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10
[ 4151.300429]  ? __lock_release.isra.0+0x1c9/0x340
[ 4151.300433]  evdev_ioctl+0x12a/0x160
[ 4151.300436]  __x64_sys_ioctl+0x13c/0x1c0
[ 4151.300438]  ? syscall_trace_enter+0x8e/0x2b0
[ 4151.300441]  do_syscall_64+0x9c/0x4e0
[ 4151.300444]  ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170
[ 4151.300447]  ? irqentry_exit+0x8c/0x5b0
[ 4151.300451]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 4151.300453] RIP: 0033:0x7f5dd4bfb46d
[ 4151.300474] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00
00 00
[ 4151.300476] RSP: 002b:00007f5daf8fd580 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 4151.300479] RAX: ffffffffffffffda RBX: 00007f5db40d03b0 RCX: 00007f5dd4bfb46d
[ 4151.300480] RDX: 00007f5daf8fd600 RSI: 0000000040304580 RDI: 0000000000000033
[ 4151.300482] RBP: 00007f5daf8fd5d0 R08: 0000000000000000 R09: 00000000ffffffff
[ 4151.300483] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f5dd3124f60
[ 4151.300484] R13: 00007f5daf8fd5e0 R14: 00007f5db40c7360 R15: 00007f5daf8fd600
[ 4151.300488]  </TASK>
[ 4368.245690] eldenring.exe (50876) used greatest stack depth: 18136 bytes left

Kernel: 6.19.0-rc1
Hardware probe: https://linux-hardware.org/?probe=2eeb9df547

Userspace:
Wine (winedevice.exe)
ELDEN RING

Could someone from the input/uinput maintainers please take a look
at the locking order between ff->mutex, dev->mutex and newdev->mutex?

This appears to be a genuine circular dependency reachable from
normal userspace activity.

--
Best Regards,
Mike Gavrilov.

Download attachment ".config.zip" of type "application/zip" (71202 bytes)

Download attachment "dmesg-6.19.0-rc1-dirty-2.zip" of type "application/zip" (47794 bytes)

Powered by blists - more mailing lists