Skip to contentSkip to conversation

scsi: ufs: core: Flush exception handling work when RPM level is zero

PATCH Superseded Thomas Yen 4 participants 8 messages Jan 29 – Jan 30

Subsystems (3)
Stable branch SCSI UFS host controller

v3 of 4 Superseded Latest is v4 →

lore
Share & tools
lore

Thomas Yen

author
#0 lore raw

PATCH v3 1/1 scsi: ufs: core: Flush exception handling work when RPM level is zero

Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0.

When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash.

Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.

Signed-off-by Thomas Yen <[email protected]>
Cc Stable Tree <[email protected]>

---
v3:
- Add logic to disable BKOPs.
v2:
- Add Cc: stable tag.
- Reformat commit message text for better line wrapping.

---
 drivers/ufs/core/ufshcd.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/ufs/core/ufshcd.c +2 -0
index 0369043ca010..8c88dd5c2cca 100644
@@ -9997,6 +9997,8 @@ static int __ufshcd_wl_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 
 	if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
 			req_link_state == UIC_LINK_ACTIVE_STATE) {
+		ufshcd_disable_auto_bkops(hba);
+		flush_work(&hba->eeh_work);
 		goto vops_suspend;
 	}

base-commit: a48ca06cf343423faa01c573aeafba9fa5f92577

Signature · 1 line
2.53.0.rc1.225.gd81095ad13-goog
Reviewed-by on v3 1/1
#1 lore raw
Quoted 13 lines · Thomas Yen

Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0.

When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race
condition where the driver could attempt to access the host controller
to handle an exception after the system had already entered a deep power-down state, resulting in a system crash.

Quoted 8 lines

Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete
and prevents illegal hardware access during the power-down sequence.

Signed-off-by Thomas Yen <[email protected]>
Cc Stable Tree <[email protected]>

---

Reviewed-by Peter Wang <[email protected]>
#2 lore raw
In reply to Thomas Yen

You should probably specify message recipients not only in the header field “Cc”.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc7#n231

…

Quoted 2 lines

---
v3:

…

Quoted 2 lines

v2:
- Add Cc: stable tag.

…

Will the tag “Fixes” become also helpful accordingly?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc7#n145

Regards,
Markus

reviewer Reviewed-by on v3 1/1
#3 lore raw
In reply to Thomas Yen
Quoted 11 lines · Thomas Yen

Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0.

When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash.

Quoted 6 lines

Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.

Signed-off-by Thomas Yen <[email protected]>
Cc Stable Tree <[email protected]>

For future patch submissions, please place the Cc: tag above the Signed-off-by tag. I think that is a widely used convention in the Linux kernel community. Anyway:

Reviewed-by Bart Van Assche <[email protected]>
author
#4 lore raw

Hi Bart,

Thanks for the tip regarding the tag ordering. I will ensure the Cc tag is placed above the Signed-off-by tag in future submissions.

I had just sent v4 (to add the missing Fixes tag) before seeing this message. Since the code logic in v4 is identical to v3, I hope that is acceptable. Thanks.

Thomas

Quoted 25 lines · Bart Van Assche
Quoted 11 lines · Thomas Yen

Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0.

When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash.

Quoted 6 lines

Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence.

Signed-off-by Thomas Yen <[email protected]>
Cc Stable Tree <[email protected]>

For future patch submissions, please place the Cc: tag above the Signed-off-by tag. I think that is a widely used convention in the Linux kernel community. Anyway:

Reviewed-by Bart Van Assche <[email protected]>
reviewer
#5 lore raw
Quoted 3 lines · Thomas Yen

I had just sent v4 (to add the missing Fixes tag) before seeing this message. Since the code logic in v4 is identical to v3, I hope that is acceptable.

It seems like our emails crossed each other. This is something that can happen.

When reposting a patch, Reviewed-by tags should be included. I don't see any Reviewed-by tags in v4 of this patch although Peter Wang had posted a Reviewed-by?

Thanks,

Bart.

author
#6 lore raw

Hi Bart,

My apologies. I missed that Peter had already replied with his Reviewed-by tag on this v3 thread before I sent v4.

Since v4 is currently bare of tags but the code is identical, would you prefer I send a v5 to consolidate all the tags and fix the Cc-tag ordering? Or should I wait for you and Peter to reply to the v4 thread?

Thanks,
Thomas

Quoted 15 lines · Bart Van Assche
Quoted 3 lines · Thomas Yen

I had just sent v4 (to add the missing Fixes tag) before seeing this message. Since the code logic in v4 is identical to v3, I hope that is acceptable.

It seems like our emails crossed each other. This is something that can happen.

When reposting a patch, Reviewed-by tags should be included. I don't see any Reviewed-by tags in v4 of this patch although Peter Wang had posted a Reviewed-by?

Thanks,

Bart.

reviewer
#7 lore raw
Quoted 2 lines · Thomas Yen

My apologies. I missed that Peter had already replied with his Reviewed-by tag on this v3 thread before I sent v4.

In the future, please leave more time between posting different versions of a patch. Posting four versions of the same patch in five days is too frequent because it doesn't give reviewers enough time to react.

Thanks,

Bart.