diff mbox series

[v4] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress

Message ID 20250522081233.2358565-1-quic_ziqichen@quicinc.com
State New
Headers show
Series [v4] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress | expand

Commit Message

Ziqi Chen May 22, 2025, 8:12 a.m. UTC 
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@quicinc.com>
Signed-off-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Ziqi Chen <quic_ziqichen@quicinc.com>
Suggested-by: Bart Van Assche <bvanassche@acm.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(+)

Comments

Bart Van Assche May 27, 2025, 9:24 p.m. UTC | #1 
On 5/22/25 1:12 AM, Ziqi Chen wrote:
> 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.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Martin K. Petersen May 28, 2025, 1:58 a.m. UTC | #2 
Ziqi,

> 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:

Applied to 6.16/scsi-staging, thanks!
Martin K. Petersen June 3, 2025, 2:35 a.m. UTC | #3 
On Thu, 22 May 2025 16:12:28 +0800, Ziqi Chen wrote:

> 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.
> 
> [...]

Applied to 6.16/scsi-queue, thanks!

[1/1] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress
      https://git.kernel.org/mkp/scsi/c/e97633492f5a
diff mbox series

Patch

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);
 }