linux-kernel - Re: [PATCH v4] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10b41d77c287393d4f6e50e712c3713839cb6a8c.camel@mediatek.com>
Date: Mon, 28 Jul 2025 06:34:38 +0000
From: Peter Wang (王信友) <peter.wang@...iatek.com>
To: "beanhuo@...ron.com" <beanhuo@...ron.com>, "avri.altman@....com"
	<avri.altman@....com>, "neil.armstrong@...aro.org"
	<neil.armstrong@...aro.org>, "quic_cang@...cinc.com" <quic_cang@...cinc.com>,
	"quic_nguyenb@...cinc.com" <quic_nguyenb@...cinc.com>,
	"quic_nitirawa@...cinc.com" <quic_nitirawa@...cinc.com>, "bvanassche@....org"
	<bvanassche@....org>, "quic_ziqichen@...cinc.com"
	<quic_ziqichen@...cinc.com>, "luca.weiss@...rphone.com"
	<luca.weiss@...rphone.com>, "konrad.dybcio@....qualcomm.com"
	<konrad.dybcio@....qualcomm.com>, "martin.petersen@...cle.com"
	<martin.petersen@...cle.com>, "quic_rampraka@...cinc.com"
	<quic_rampraka@...cinc.com>, "junwoo80.lee@...sung.com"
	<junwoo80.lee@...sung.com>, "mani@...nel.org" <mani@...nel.org>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Tze-nan Wu (吳澤南) <Tze-nan.Wu@...iatek.com>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"manivannan.sadhasivam@...aro.org" <manivannan.sadhasivam@...aro.org>,
	"alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
	"James.Bottomley@...senPartnership.com"
	<James.Bottomley@...senPartnership.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] scsi: ufs: core: Don't perform UFS clkscale if host
 asyn scan in progress

On Fri, 2025-07-25 at 07:54 -0700, Bart Van Assche wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On 7/25/25 2:13 AM, Peter Wang (王信友) wrote:
> > Could consider luns_avail instead mutex?
> 
> That would be wrong. I think it is essential that scan_mutex is used
> in
> this patch. Additionally, the lock inversion is between devfreq->lock
> and (c->notifiers)->rwsem so it seems unlikely to me that Ziqi's
> patch
> is the patch that introduced the reported lock inversion.
> 
> Bart.


Hi Bart,

This is a complex situation involving six locks, which may result in
a circular locking dependency.
Let me explain how a new circular locking dependency is formed:

CPU0: take &(c->notifiers)->rwsem#2, wait &devfreq->lock
CPU1: take &devfreq->lock, wait &shost->scan_mutex,  <= Lock introduced
by this patch
CPU2: take &shost->scan_mutex, wait &q->sysfs_lock
CPU3: take &q->sysfs_lock, wait cpu_hotplug_lock
CPU4: take cpu_hotplug_lock, wait subsys mutex#2
CPU5: take subsys mutex#2, wait &(c->notifiers)->rwsem#2  <= Hold By
CPU0

ufshcd_add_lus triggers ufshcd_devfreq_init.
This means that clock scaling can be performed while scanning LUNs.
However, this patch adds another lock to prevent clock scaling 
before the LUN scan is complete. This is a paradoxical situation. 
If we cannnot do clock scaling before the LUN scan is complete, 
then why we start clock scaling before it?

If we don’t put it in luns_avail (start clock scaling after LUNs 
scan complete), do you have a better suggestion
for where to initialize clock scaling (ufshcd_devfreq_init)?

Thanks.
Peter