CVE-2026-64100: drm/msm: Fix shrinker deadlock

In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix shrinker deadlock

With PROVELOCKING on an Snapdragon X1 and VM reclaim pressure, we see:

====================================================== WARNING: possible circular locking dependency detected 7.0.0-debug+ #43 Tainted: G W ------------------------------------------------------ kswapd0/82 is trying to acquire lock: ffff800080ec3870 (reservationwwclassacquire){+.+.}-{0:0}, at: msmgemshrinkerscan+0x17c/0x400 [msm]

but task is already holding lock: ffffc31709b263b8 (fsreclaim){+.+.}-{0:0}, at: balancepgdat+0x88/0x988

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (fsreclaim){+.+.}-{0:0}: lockacquire+0x4d0/0xad0 lockacquire.part.0+0xc4/0x248 lockacquire+0x8c/0x248 fsreclaimacquire+0xd0/0xf0 dmaresvlockdep+0x224/0x348 dooneinitcall+0x84/0x5d0 doinitcalls+0x194/0x1d8 kernelinitfreeable+0x128/0x180 kernelinit+0x2c/0x160 retfromfork+0x10/0x20

-> #1 (reservationwwclassmutex){+.+.}-{4:4}: lockacquire+0x4d0/0xad0 lockacquire.part.0+0xc4/0x248 lockacquire+0x8c/0x248 dmaresvlockdep+0x1a8/0x348 dooneinitcall+0x84/0x5d0 doinitcalls+0x194/0x1d8 kernelinitfreeable+0x128/0x180 kernelinit+0x2c/0x160 retfromfork+0x10/0x20

-> #0 (reservationwwclassacquire){+.+.}-{0:0}: checkprevadd+0x114/0x790 validatechain+0x594/0x6f0 lockacquire+0x4d0/0xad0 lockacquire.part.0+0xc4/0x248 lockacquire+0x8c/0x248 drmgemlruscan+0x1ac/0x440 msmgemshrinkerscan+0x17c/0x400 [msm] doshrinkslab+0x150/0x4a0 shrinkslab+0x144/0x460 shrinkone+0x9c/0x1b0 shrinkmany+0x27c/0x5c0 shrinknode+0x344/0x550 balancepgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 retfromfork+0x10/0x20

other info that might help us debug this: Chain exists of: reservationwwclassacquire --> reservationwwclassmutex --> fsreclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fsreclaim); lock(reservationwwclassmutex); lock(fsreclaim); lock(reservationwwclassacquire);

DEADLOCK 1 lock held by kswapd0/82: #0: ffffc31709b263b8 (fsreclaim){+.+.}-{0:0}, at: balancepgdat+0x88/0x988

stack backtrace: CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full) Tainted: [W]=WARN Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025 Call trace: showstack+0x20/0x40 (C) dumpstacklvl+0x9c/0xd0 dumpstack+0x18/0x30 printcircularbug+0x114/0x120 checknoncircular+0x178/0x198 checkprevadd+0x114/0x790 validatechain+0x594/0x6f0 lockacquire+0x4d0/0xad0 lockacquire.part.0+0xc4/0x248 lockacquire+0x8c/0x248 drmgemlruscan+0x1ac/0x440 msmgemshrinkerscan+0x17c/0x400 [msm] doshrinkslab+0x150/0x4a0 shrinkslab+0x144/0x460 shrinkone+0x9c/0x1b0 shrinkmany+0x27c/0x5c0 shrinknode+0x344/0x550 balancepgdat+0x2c0/0x988 kswapd+0x11c/0x318 kthread+0x10c/0x128 retfromfork+0x10/0x20

kswapd0 holding fsreclaim calls the MSM shrinker, which calls dmaresvlock. This in turn acquires fsreclaim.

Fix this deadlock by using dmaresvtrylock() instead, dropping the subsequently unused passed wait-wound lock 'ticket'.

Patchwork: https://patchwork.freedesktop.org/patch/723564/ [rob: fixup compile errors, replace lockdep splat with somethin ---truncated---