All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "HOYOUNG SEO" <hy50.seo@samsung.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v4 2/2] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM
Date: Thu, 05 Nov 2026 04:40:52 +0000	[thread overview]
Message-ID: <sashiko-outbox-198555@kernel.org> (raw)
In-Reply-To: <a5f3b13e7c2ae3cb39dfd078e637fd6c4424356e.1793851432.git.hy50.seo@samsung.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: ufs: core: concurrent error recovery during ufshcd_wl_poweroff()
--

commit 6f60eb14bc24b472557f86d1f4db1435491fade7
Author: HOYOUNG SEO <hy50.seo@samsung.com>

scsi: ufs: core: Limit early link recovery in the error handler to runtime PM

This commit restricts the early link recovery path in ufshcd_err_handler()
to runtime PM operations by introducing hba->runtime_pm_in_progress, so
that system PM and shutdown use the regular error handling path instead of
resetting the link concurrently.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 3b5580ac390cb..e3908d6af3ae4 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -7089,11 +7089,15 @@ static void ufshcd_err_handler(struct work_struct *work)
>  		 * Use ufshcd_rpm_get_noresume() here to safely perform link
>  		 * recovery even if an error occurs during runtime suspend or
>  		 * runtime resume. This avoids potential deadlocks that could
> -		 * happen if we tried to resume the device while a PM operation
> -		 * is already in progress.
> +		 * happen if we tried to resume the device while a runtime PM
> +		 * operation is already in progress.
> +		 *
> +		 * Do not do this for system PM and shutdown. The system PM
> +		 * callbacks hold host_sem, so the regular path below runs
> +		 * after them instead of resetting the link concurrently.
>  		 */
>  		ufshcd_rpm_get_noresume(hba);
> -		if (hba->pm_op_in_progress) {
> +		if (hba->runtime_pm_in_progress) {
>  			ufshcd_link_recovery(hba);
>  			ufshcd_rpm_put(hba);
>  			return;

[Severity: High]
Can this allow ufshcd_err_handler() to run regular error recovery
concurrently with hibernation poweroff in ufshcd_wl_poweroff()?

During hibernation, the PM core runs .freeze (ufshcd_wl_suspend(), which
takes hba->host_sem) followed by .thaw (ufshcd_wl_resume(), which releases
hba->host_sem) before writing the hibernation image, and then invokes
.poweroff:

drivers/ufs/core/ufshcd.c:ufshcd_wl_poweroff() {
	struct scsi_device *sdev = to_scsi_device(dev);
	struct ufs_hba *hba = shost_priv(sdev->host);

	__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
	return 0;
}

When ufshcd_wl_poweroff() calls __ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM),
hba->runtime_pm_in_progress is set to false. However, unlike
ufshcd_wl_suspend(), ufshcd_wl_poweroff() does not hold hba->host_sem, and
unlike ufshcd_wl_shutdown(), it does not set hba->shutting_down = true.

If an error interrupt schedules hba->eh_work while ufshcd_wl_poweroff() is
running, ufshcd_err_handler() will skip the early return because
hba->runtime_pm_in_progress is false, acquire the uncontended
hba->host_sem, see ufshcd_err_handling_should_stop(hba) return false, and
proceed with ufshcd_err_handling_prepare() and ufshcd_reset_and_restore()
at the same time __ufshcd_wl_suspend() is powering down the device and
link.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793851432.git.hy50.seo@samsung.com?part=2

      reply	other threads:[~2026-11-05  4:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20261105042040epcas2p2af9610d36007ff1e247c8131aeb3edfc@epcas2p2.samsung.com>
2026-11-05  4:16 ` [PATCH v4 0/2] scsi: ufs: core: Avoid redundant link recovery from the error handler during PM HOYOUNG SEO
2026-11-05  4:16   ` [PATCH v4 1/2] scsi: ufs: core: Clear saved errors in ufshcd_link_recovery HOYOUNG SEO
2026-11-05  4:16   ` [PATCH v4 2/2] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM HOYOUNG SEO
2026-11-05  4:40     ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-198555@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=hy50.seo@samsung.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.