From: sashiko-bot@kernel.org
To: "HOYOUNG SEO" <hy50.seo@samsung.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v7 2/3] scsi: ufs: core: Hold host_sem in ufshcd_wl_poweroff()
Date: Fri, 06 Nov 2026 06:33:06 +0000 [thread overview]
Message-ID: <sashiko-outbox-200897@kernel.org> (raw)
In-Reply-To: <c408e7a7167984a07dc714f43273d029b8904939.1793943246.git.hy50.seo@samsung.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] scsi: ufs: core: missing error and RPM handling in
ufshcd_wl_poweroff()
--
commit 9a163b2c91f3c9901825d9d544ee48c174c9b6c6
Author: HOYOUNG SEO <hy50.seo@samsung.com>
scsi: ufs: core: Hold host_sem in ufshcd_wl_poweroff()
This commit acquires hba->host_sem in ufshcd_wl_poweroff() before calling
__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM) so that error recovery is
serialized against hibernation poweroff and hba->host_sem remains balanced
if hibernation is aborted and ufshcd_wl_resume() runs.
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 5a3ca3b4e6666..c2c34b044c3ec 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -11583,6 +11583,8 @@ static int ufshcd_wl_poweroff(struct device *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> struct ufs_hba *hba = shost_priv(sdev->host);
>
> + /* Released by ufshcd_wl_resume() if hibernation is aborted. */
> + down(&hba->host_sem);
> __ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);
> return 0;
> }
[Severity: Medium]
What happens if __ufshcd_wl_suspend() fails here or if dev is already
runtime-suspended?
When __ufshcd_wl_suspend() fails, it drops its initial ufshcd_hold(hba)
via ufshcd_release(hba) before returning:
drivers/ufs/core/ufshcd.c:__ufshcd_wl_suspend() {
...
if (ret) {
ufshcd_update_evt_hist(hba, UFS_EVT_WL_SUSP_ERR, (u32)ret);
hba->clk_gating.is_suspended = false;
ufshcd_release(hba);
}
...
}
Unlike ufshcd_wl_suspend(), ufshcd_wl_poweroff() ignores that failure,
leaves hba->host_sem held (blocking ufshcd_err_handler()), and returns 0
so the parent controller suspends while the UFS device and link are still
active. If hibernation is then aborted, ufshcd_wl_resume() calls
__ufshcd_wl_resume(hba, UFS_SYSTEM_PM), which calls ufshcd_release(hba) a
second time and underflows hba->clk_gating.active_reqs.
In addition, ufshcd_suspend_prepare() leaves ufs_device_wlun
runtime-suspended when ufshcd_rpm_ok_for_spm(hba) is true, but
ufshcd_wl_poweroff() does not check pm_runtime_suspended(dev) (unlike
ufshcd_wl_suspend() and ufshcd_wl_resume()): if the device is in
UFS_SLEEP_PWR_MODE or UIC_LINK_HIBERN8_STATE, __ufshcd_wl_suspend() hits
!ufshcd_is_ufs_dev_active(hba) || !ufshcd_is_link_active(hba), schedules
ufshcd_force_error_recovery(hba) (which blocks on hba->host_sem), and
clears hba->clk_gating.is_suspended; if it is already in
UFS_POWERDOWN_PWR_MODE and UIC_LINK_OFF_STATE, __ufshcd_wl_suspend() takes
a second ufshcd_hold(hba) that ufshcd_wl_resume() never releases because
pm_runtime_suspended(dev) is true.
Finally, ufshcd_wl_poweroff() does not set hba->is_sys_suspended = true on
success like ufshcd_wl_suspend() does, so if __ufshcd_wl_resume() fails
during restore, ufshcd_err_handling_prepare() will skip re-enabling
regulators, clocks, and IRQs.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793943246.git.hy50.seo@samsung.com?part=2
next prev parent reply other threads:[~2026-11-06 6:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261106061544epcas2p4b1ebab9e2c0e041ee52ff724caf8a9e8@epcas2p4.samsung.com>
2026-11-06 6:11 ` [PATCH v7 0/3] scsi: ufs: core: Avoid redundant link recovery from the error handler during PM HOYOUNG SEO
2026-11-06 6:11 ` [PATCH v7 1/3] scsi: ufs: core: Clear saved errors in ufshcd_link_recovery() HOYOUNG SEO
2026-11-06 6:11 ` [PATCH v7 2/3] scsi: ufs: core: Hold host_sem in ufshcd_wl_poweroff() HOYOUNG SEO
2026-11-06 6:33 ` sashiko-bot [this message]
2026-11-06 21:56 ` Bart Van Assche
2026-11-06 6:11 ` [PATCH v7 3/3] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM HOYOUNG SEO
2026-11-06 21:57 ` 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-200897@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