linux-kernel - [linux-next] potential deadlock in ufshcd?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <DERQ2FF2WO70.3I04I9XAG5V6D@linaro.org>
Date: Sun, 07 Dec 2025 05:07:06 +0000
From: "Alexey Klimov" <alexey.klimov@...aro.org>
To: <linux-scsi@...r.kernel.org>, <mani@...nel.org>,
 <linux-arm-msm@...r.kernel.org>
Cc: <alim.akhtar@...sung.com>, <avri.altman@....com>, <bvanassche@....org>,
 <linux-next@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [linux-next] potential deadlock in ufshcd?

Hi all,

for around ~1 week or a bit longer I cannot boot Qualcomm RB5 board
(based on sm8250, dts file is qrb5165-rb5.dts) with recent linux-next
trees. I think I see similar problem on sm8750-mtp board (at least
the behaviour is the same and the same time out message).

Basically the booting stops somewhere in initramfs, looks like when
loading modules from udev and eventually it prints:

Timed out while waiting for udev queue to empty.

I boot RB5 board with rootfs on usb drive but the boot process
is broken anyway.
6.17 and 6.18 from mainline boot fine with no issues.
6.17 boots on sm8750-mtp with no problems but it is broken on 6.18
before reaching initramfs so I guess it is better to focus on RB5.

Started to debug it a bit and only two things pop up in log.
List of blocked tasks seems to be a bit boring here, just udev
waiting on __schedule() but list of all held locks in kernel
shows (apart from other things) a couple of locks held by
ufshcd_devfreq_scale()/ufshcd_query_flag():

[  184.523804] 7 locks held by kworker/u32:3/71:
[  184.528292]  #0: ffff000081eca148 ((wq_completion)devfreq_wq){+.+.}-{0:0}, at: process_one_work+0x184/0x608
[  184.538304]  #1: ffff800080963de8 ((work_completion)(&(&devfreq->work)->work)){+.+.}-{0:0}, at: process_one_work+0x1ac/0x608
[  184.549835]  #2: ffff00008cbc1078 (&devfreq->lock){+.+.}-{4:4}, at: devfreq_monitor+0x2c/0x1a0
[  184.558697]  #3: ffff00008cdb80e0 (&shost->scan_mutex){+.+.}-{4:4}, at: ufshcd_devfreq_scale+0x5c/0x460
[  184.568360]  #4: ffff00008cdb9f30 (&hba->wb_mutex){+.+.}-{4:4}, at: ufshcd_devfreq_scale+0x74/0x460
[  184.577675]  #5: ffff00008cdb9a40 (&hba->dev_cmd.lock){+.+.}-{4:4}, at: ufshcd_query_flag+0x5c/0x1e8
[  184.587074]  #6: ffff00008cdb9fc8 (&hba->clk_scaling_lock){++++}-{4:4}, at: ufshcd_query_flag+0x6c/0x1e8

After I disabled ufs_mem_hc and ufs_mem_phy via status = "disabled"
in RB5 device tree the kernel immediately booted with no problems
from usb drive.

Booting of sm8750-mtp from usb might be a bit tricky.

Is it a known problem? I can test potential changes to resolve this
or try to collect more debug data if needed.

Best regards,
Alexey

View attachment "linux-next-fail_locks.txt" of type "text/plain" (80320 bytes)