From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D06B2E7620; Thu, 3 Jul 2025 14:47:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751554023; cv=none; b=atxe1eeCF7E5Lt2T3ZyXyGaEB+7AczryVjWolNBU/MQ4yR9jRb8ZNRCDTUK+ajO9X87/8sxdobAdrcHdiaAsDJrV4E+HXmsbMRx49x4I7iNEKAj7yEJRINaFiYQyqSoJuJq1tI0EZAEDn4EpyzTAQiOae0eJetJy3xcYsBrIJFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751554023; c=relaxed/simple; bh=klaSOp20f6oz8Fr9dU4WPz9V95UDEw/7sAtG+ZvYzJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E0p5ZrZM6LTW7aGjBqDQ2AKIOmCGJebHadqwkL611qyFlym5l2kfLyt750THKQJDopAiCInAa4PmEAb1uy+PcXStI/CZexVDgo0tyktACBuYVz2Yf4tNEES0SAkfD37AH75/t7o7wzJZJyToEQCAiGyvF8q8xGvgVRbbMTXE9tM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=QFZIWyrJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="QFZIWyrJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A86C3C4CEE3; Thu, 3 Jul 2025 14:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1751554023; bh=klaSOp20f6oz8Fr9dU4WPz9V95UDEw/7sAtG+ZvYzJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QFZIWyrJzrwtf69+tdJcF4JtU11uHlHIOpd1G+wQ/4+7sTUJwDjHAb7NE32s+nukr P0ylSZ/nz7U9wBreiQrOKS9Onr/e/oRjgPLe6IBGmwrGA0P0N2geNsD6pHE7CzxX8U FM+jf/xCf+uvYou8h8J/u3jwrZtm7RKxuT3hdWYY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Can Guo , Ziqi Chen , Bart Van Assche , "Martin K. Petersen" , Sasha Levin Subject: [PATCH 6.12 055/218] scsi: ufs: core: Dont perform UFS clkscaling during host async scan Date: Thu, 3 Jul 2025 16:40:03 +0200 Message-ID: <20250703143958.134578773@linuxfoundation.org> X-Mailer: git-send-email 2.50.0 In-Reply-To: <20250703143955.956569535@linuxfoundation.org> References: <20250703143955.956569535@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ziqi Chen [ Upstream commit e97633492f5a3eca7b3ff03b4ef6f993017f7955 ] 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 in ufshcd_clock_scaling_unprepare(). 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 I/O 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 Signed-off-by: Can Guo Signed-off-by: Ziqi Chen Link: https://lore.kernel.org/r/20250522081233.2358565-1-quic_ziqichen@quicinc.com Suggested-by: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin --- 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 374f505fec3d1..c5cef57e64ce3 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -1392,6 +1392,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); @@ -1402,6 +1403,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; } @@ -1423,6 +1425,7 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, int err, bool sc mutex_unlock(&hba->wb_mutex); blk_mq_unquiesce_tagset(&hba->host->tag_set); + mutex_unlock(&hba->host->scan_mutex); ufshcd_release(hba); } -- 2.39.5