Linux SCSI subsystem development
 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 v8 3/3] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM
Date: Mon, 09 Nov 2026 05:21:28 +0000	[thread overview]
Message-ID: <sashiko-outbox-204431@kernel.org> (raw)
In-Reply-To: <2052256418.81794200283664.JavaMail.epsvc@epcpadp2new>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] scsi: ufs: core: unsynchronized link recovery in
  ufshcd_err_handler()
--

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

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

This commit replaces the hba->pm_op_in_progress check in
ufshcd_err_handler() with ufshcd_rpm_transition_in_progress() so that early
link recovery without hba->host_sem only runs when the WLUN runtime PM
status is RPM_SUSPENDING or RPM_RESUMING.

> diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
> index 99f654b79035f..c576f648f242d 100644
> --- a/drivers/ufs/core/ufshcd-priv.h
> +++ b/drivers/ufs/core/ufshcd-priv.h
> @@ -418,6 +418,19 @@ static inline void ufshcd_rpm_put(struct ufs_hba *hba)
>  	pm_runtime_put(&hba->ufs_device_wlun->sdev_gendev);
>  }
>  
> +/* Whether a runtime suspend or resume of the WLUN is in progress. */
> +static inline bool ufshcd_rpm_transition_in_progress(struct ufs_hba *hba)
> +{
> +#ifdef CONFIG_PM
> +	enum rpm_status status =
> +		READ_ONCE(hba->ufs_device_wlun->sdev_gendev.power.runtime_status);
> +
> +	return status == RPM_SUSPENDING || status == RPM_RESUMING;
> +#else
> +	return false;
> +#endif
> +}
> +
>  /**
>   * ufs_is_valid_unit_desc_lun - checks if the given LUN has a unit descriptor
>   * @dev_info: pointer of instance of struct ufs_dev_info
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index c2c34b044c3ec..1608a856cac71 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -7094,9 +7094,14 @@ static void ufshcd_err_handler(struct work_struct *work)
>  		 * runtime resume. This avoids potential deadlocks that could
>  		 * happen if we tried to resume the device while a PM operation
>  		 * is already in progress.
> +		 *
> +		 * Do this only while a runtime PM operation is in progress. The
> +		 * system PM and poweroff callbacks hold host_sem, and
> +		 * shutting_down makes the regular path below stop, so it does
> +		 * not reset the link concurrently with them.
>  		 */
>  		ufshcd_rpm_get_noresume(hba);
> -		if (hba->pm_op_in_progress) {
> +		if (ufshcd_rpm_transition_in_progress(hba)) {
>  			ufshcd_link_recovery(hba);
>  			ufshcd_rpm_put(hba);
>  			return;

[Severity: High]
Does checking runtime_status here widen the window for unsynchronized
ufshcd_link_recovery() outside the ufshcd_hold() region of
__ufshcd_wl_suspend() and __ufshcd_wl_resume()?

The runtime PM core sets runtime_status to RPM_SUSPENDING before
sdev_runtime_suspend() runs blk_pre_runtime_suspend(), and keeps
RPM_SUSPENDING or RPM_RESUMING until after sdev_runtime_suspend() or
sdev_runtime_resume() returns.  That window spans before
__ufshcd_wl_suspend() calls ufshcd_hold() and after __ufshcd_wl_suspend() or
__ufshcd_wl_resume() calls ufshcd_release() and clears
hba->pm_op_in_progress:

CPU0                                  CPU1 (eh_wq)
rpm_suspend()
  runtime_status = RPM_SUSPENDING
  ...
  __ufshcd_wl_suspend()
    ufshcd_hold(hba)
    ufshcd_link_state_transition()
      /* fails */
    ufshcd_force_error_recovery(hba)
      queue_work(..., &hba->eh_work)
    ...
    ufshcd_release(hba)
    hba->pm_op_in_progress = false
                                      ufshcd_err_handler()
                                        ufshcd_rpm_transition_in_progress()
                                          /* still RPM_SUSPENDING */
                                        ufshcd_link_recovery(hba)
                                          /* runs without ufshcd_hold() */
  blk_post_runtime_suspend()
  runtime_status = RPM_ACTIVE

Because ufshcd_link_recovery() runs in this window without ufshcd_hold(),
hba->host_sem, or ufshcd_err_handling_prepare(), it can access controller
MMIO registers while clocks are gated off (for example, during
blk_pre_runtime_suspend() or after ufshcd_release()), or reset and activate
the host and link after a successful __ufshcd_wl_suspend() right before
rpm_suspend() marks the WLUN RPM_SUSPENDED.

Also, during runtime PM itself, if a UIC error schedules eh_work while
__ufshcd_wl_resume() fails ufshcd_uic_hibern8_exit(), or while
__ufshcd_wl_suspend() rolls back at set_dev_active, ufshcd_err_handler() and
the runtime PM callback still run ufshcd_link_recovery() concurrently.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/728258269.41794200283102.JavaMail.epsvc@epcpadp2new?part=3

  reply	other threads:[~2026-11-09  5:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20261109041346epcas2p403d660b62bc9f227fef868e8b19816af@epcas2p4.samsung.com>
     [not found] ` <cover.1794196863.git.hy50.seo@samsung.com>
2026-11-09  4:09   ` [PATCH v8 1/3] scsi: ufs: core: Clear saved errors in ufshcd_link_recovery() HOYOUNG SEO
2026-11-09 15:28     ` Bean Huo
2026-11-09  4:09   ` [PATCH v8 2/3] scsi: ufs: core: Hold host_sem in ufshcd_wl_poweroff() HOYOUNG SEO
2026-11-09  5:18     ` sashiko-bot
2026-11-09  9:34     ` Peter Wang
2026-11-09 18:19       ` Bart Van Assche
2026-11-09  4:09   ` [PATCH v8 3/3] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM HOYOUNG SEO
2026-11-09  5:21     ` sashiko-bot [this message]
2026-11-09  9:32     ` Peter Wang
2026-11-09 17:08     ` Bean Huo
2026-11-09 18:20       ` Bart Van Assche

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-204431@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox