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

Message-Id: <20250522081233.2358565-1-quic_ziqichen@quicinc.com>
Date: Thu, 22 May 2025 16:12:28 +0800
From: Ziqi Chen <quic_ziqichen@...cinc.com>
To: quic_cang@...cinc.com, bvanassche@....org, mani@...nel.org,
        beanhuo@...ron.com, avri.altman@....com, junwoo80.lee@...sung.com,
        martin.petersen@...cle.com, quic_ziqichen@...cinc.com,
        quic_nguyenb@...cinc.com, quic_nitirawa@...cinc.com,
        quic_rampraka@...cinc.com, neil.armstrong@...aro.org,
        luca.weiss@...rphone.com, konrad.dybcio@....qualcomm.com,
        peter.wang@...iatek.com
Cc: linux-arm-msm@...r.kernel.org, linux-scsi@...r.kernel.org,
        Alim Akhtar <alim.akhtar@...sung.com>,
        "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        linux-kernel@...r.kernel.org (open list)
Subject: [PATCH v4] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress

When preparing for UFS clock scaling, the UFS driver will quiesce all sdevs
queues in the UFS SCSI host tagset list and then unquiesce them when UFS
clock scaling unpreparing. If the UFS SCSI host async scan is in progress
at this time, some LUs may be added to the tagset list between UFS clkscale
prepare and unprepare. This can cause two issues:

1. During clock scaling, there may be IO requests issued through new added
queues that have not been quiesced, leading to task abort issue.

2. These new added queues that have not been quiesced will be unquiesced as
well when UFS clkscale is unprepared, resulting in warning prints.

Therefore, use the mutex lock scan_mutex in ufshcd_clock_scaling_prepare()
and ufshcd_clock_scaling_unprepare() to protect it.

Co-developed-by: Can Guo <quic_cang@...cinc.com>
Signed-off-by: Can Guo <quic_cang@...cinc.com>
Signed-off-by: Ziqi Chen <quic_ziqichen@...cinc.com>
Suggested-by: Bart Van Assche <bvanassche@....org>

---
v1 -> v2:
Move whole clkscale Initialize process out of ufshcd_add_lus().

v2 -> v3:
Add check for the return value of ufshcd_add_lus().

v3 -> v4:
1. Using lock 'scan_mutex' instead of checking flag 'scan_mutex'.
2. Update patch name and commit message.
---
 drivers/ufs/core/ufshcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index d7ff24b48de3..a7513f256057 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -1397,6 +1397,7 @@ 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);
 	blk_mq_quiesce_tagset(&hba->host->tag_set);
 	mutex_lock(&hba->wb_mutex);
 	down_write(&hba->clk_scaling_lock);
@@ -1407,6 +1408,7 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba, u64 timeout_us)
 		up_write(&hba->clk_scaling_lock);
 		mutex_unlock(&hba->wb_mutex);
 		blk_mq_unquiesce_tagset(&hba->host->tag_set);
+		mutex_unlock(&hba->host->scan_mutex);
 		goto out;
 	}
 
@@ -1428,6 +1430,7 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, int err)
 	mutex_unlock(&hba->wb_mutex);
 
 	blk_mq_unquiesce_tagset(&hba->host->tag_set);
+	mutex_unlock(&hba->host->scan_mutex);
 	ufshcd_release(hba);
 }
 
-- 
2.34.1