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

Message-ID: <efdd6dfcca06680bedc02a70fae1b35485083250.camel@mediatek.com>
Date: Mon, 4 Aug 2025 12:43:59 +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_nitirawa@...cinc.com" <quic_nitirawa@...cinc.com>,
	"quic_nguyenb@...cinc.com" <quic_nguyenb@...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>, "junwoo80.lee@...sung.com"
	<junwoo80.lee@...sung.com>, "mani@...nel.org" <mani@...nel.org>,
	"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
	"quic_rampraka@...cinc.com" <quic_rampraka@...cinc.com>
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 Mon, 2025-08-04 at 15:54 +0800, Ziqi Chen wrote:
> 
> Hi  Peter && Bart,
> 
> How do you think about using
> 
> if (!mutex_trylock(&hba->host->scan_mutex))
>         return -EAGAIN;
> 
> instead of
> 
> mutex_lock(&hba->host->scan_mutex);
> 
> But this way will cause one line print of devfreq failed.
> 
> BRs
> Ziqi


Hi Ziqi,

After applying the patch below, the lockdep issue no longer appears.
Would you be able to upstream this fix?

---

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 2ff91f2..0af34ce 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1435,7 +1435,8 @@ static int ufshcd_clock_scaling_prepare(struct
ufs_hba *hba, u64 timeout_us)
 	 * make sure that there are no outstanding requests when
 	 * clock scaling is in progress
 	 */
-	mutex_lock(&hba->host->scan_mutex);
+	if(!mutex_trylock(&hba->host->scan_mutex))
+		return -EAGAIN;
 	blk_mq_quiesce_tagset(&hba->host->tag_set);
 	mutex_lock(&hba->wb_mutex);
 	down_write(&hba->clk_scaling_lock);


Thanks.
Peter