From: sashiko-bot@kernel.org
To: "HOYOUNG SEO" <hy50.seo@samsung.com>, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v6 3/3] scsi: ufs: core: Set shutting_down in ufshcd_wl_poweroff()
Date: Fri, 06 Nov 2026 02:32:50 +0000 [thread overview]
Message-ID: <sashiko-outbox-200603@kernel.org> (raw)
In-Reply-To: <66845a28b3014bb53b7f1332c258009b80707297.1793931113.git.hy50.seo@samsung.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] scsi: ufs: core: ufshcd_wl_poweroff() breaks ufs_mtk_system_suspend()
- [High] scsi: ufs: core: ufshcd_wl_poweroff() corrupts state on restore rollback
--
commit 744164ab90d2e91d1a44bcd61cfe43ee02a7ac78
Author: HOYOUNG SEO <hy50.seo@samsung.com>
scsi: ufs: core: Set shutting_down in ufshcd_wl_poweroff()
This commit sets hba->shutting_down under hba->host_sem in
ufshcd_wl_poweroff() before calling __ufshcd_wl_suspend() so that the error
handler does not attempt link recovery during hibernation poweroff.
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 8571e91263e51..e59cdc224ef96 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -11592,6 +11592,10 @@ static int ufshcd_wl_poweroff(struct device *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> struct ufs_hba *hba = shost_priv(sdev->host);
>
> + down(&hba->host_sem);
> + hba->shutting_down = true;
[Severity: High]
Will setting hba->shutting_down = true in ufshcd_wl_poweroff() cause
hibernation poweroff to fail on MediaTek controllers?
During hibernation poweroff via:
hibernate() ->
power_down() ->
hibernation_platform_enter() ->
dpm_suspend_start() ->
dpm_suspend()
devices are suspended in child-before-parent order, so ufshcd_wl_poweroff()
on the child device wlun (&hba->ufs_device_wlun->sdev_gendev) runs before the
parent controller's .poweroff callback on hba->dev.
In drivers/ufs/host/ufs-mediatek.c, ufs_mtk_pm_ops wires .poweroff to
ufs_mtk_system_suspend():
static const struct dev_pm_ops ufs_mtk_pm_ops = {
SYSTEM_SLEEP_PM_OPS(ufs_mtk_system_suspend, ufs_mtk_system_resume)
...
};
And ufs_mtk_system_suspend() checks hba->shutting_down at entry:
static int ufs_mtk_system_suspend(struct device *dev)
{
struct ufs_hba *hba = dev_get_drvdata(dev);
struct arm_smccc_res res;
int ret;
if (hba->shutting_down) {
ret = -EBUSY;
goto out;
}
When ufshcd_wl_poweroff() sets hba->shutting_down = true first, won't
ufs_mtk_system_suspend() immediately fail and abort hibernation?
> + up(&hba->host_sem);
[Severity: High]
What happens if hibernation poweroff rolls back and invokes .restore?
In drivers/ufs/core/ufshcd.c, ufshcd_wl_pm_ops pairs .poweroff with .restore:
static const struct dev_pm_ops ufshcd_wl_pm_ops = {
#ifdef CONFIG_PM_SLEEP
.suspend = ufshcd_wl_suspend,
.resume = ufshcd_wl_resume,
.freeze = ufshcd_wl_suspend,
.thaw = ufshcd_wl_resume,
.poweroff = ufshcd_wl_poweroff,
.restore = ufshcd_wl_resume,
#endif
If hibernation_platform_enter() aborts after ufshcd_wl_poweroff() has run
(for example due to a pending wakeup event or a later device failing its
poweroff callback), dpm_resume_end() calls ufshcd_wl_resume():
static int ufshcd_wl_resume(struct device *dev)
{
...
if (!ret)
hba->is_sys_suspended = false;
up(&hba->host_sem);
return ret;
}
Unlike ufshcd_wl_suspend(), which keeps hba->host_sem held until
ufshcd_wl_resume() releases it, ufshcd_wl_poweroff() releases hba->host_sem
immediately, and ufshcd_wl_resume() never clears hba->shutting_down.
After a hibernation rollback, doesn't this perform an unbalanced
up(&hba->host_sem) (incrementing the semaphore count to 2) and leave
hba->shutting_down permanently set to true on the running system, disabling
error recovery in ufshcd_err_handling_should_stop() and blocking user
accesses in ufshcd_is_user_access_allowed()?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793931113.git.hy50.seo@samsung.com?part=3
next prev parent reply other threads:[~2026-11-06 2:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261106022018epcas2p44e9634ca254c1a5d4c1ecb64723512ef@epcas2p4.samsung.com>
2026-11-06 2:15 ` [PATCH v6 0/3] scsi: ufs: core: Avoid redundant link recovery from the error handler during PM HOYOUNG SEO
2026-11-06 2:15 ` [PATCH v6 1/3] scsi: ufs: core: Clear saved errors in ufshcd_link_recovery() HOYOUNG SEO
2026-11-06 4:46 ` Bart Van Assche
2026-11-06 7:08 ` Peter Wang
2026-11-06 2:15 ` [PATCH v6 2/3] scsi: ufs: core: Limit early link recovery in the error handler to runtime PM HOYOUNG SEO
2026-11-06 4:48 ` Bart Van Assche
2026-11-06 7:10 ` Peter Wang
2026-11-06 7:58 ` hoyoung seo
2026-11-06 9:44 ` Peter Wang
2026-11-06 19:15 ` Bart Van Assche
2026-11-09 9:29 ` Peter Wang
2026-11-06 2:15 ` [PATCH v6 3/3] scsi: ufs: core: Set shutting_down in ufshcd_wl_poweroff() HOYOUNG SEO
2026-11-06 2:32 ` sashiko-bot [this message]
2026-11-06 4:49 ` Bart Van Assche
2026-11-06 6:09 ` hoyoung seo
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-200603@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.