[PATCH v1] ufs: core: fix deadlock when rtc update
Bart Van Assche
bvanassche at acm.org
Fri Jul 12 10:34:31 PDT 2024
On 7/12/24 2:43 AM, peter.wang at mediatek.com wrote:
> Three have deadlock when runtime suspend wait flush rtc work,
> and rtc work call ufshcd_rpm_put_sync to wait runtime resume.
"Three have"? The above description is very hard to understand. Please
improve it.
> - /* Update RTC only when there are no requests in progress and UFSHCI is operational */
> - if (!ufshcd_is_ufs_dev_busy(hba) && hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL)
> + /*
> + * Update RTC only when
> + * 1. there are no requests in progress
> + * 2. UFSHCI is operational
> + * 3. pm operation is not in progress
> + */
> + if (!ufshcd_is_ufs_dev_busy(hba) &&
> + hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL &&
> + !hba->pm_op_in_progress)
> ufshcd_update_rtc(hba);
>
> if (ufshcd_is_ufs_dev_active(hba) && hba->dev_info.rtc_update_period)
The above seems racy to me. I don't think there is any mechanism that
prevents that hba->pm_op_in_progress is set after it has been checked
and before ufshcd_update_rtc() is called. Has it been considered to add
an ufshcd_rpm_get_sync_nowait() call before the hba->pm_op_in_progress
check and a ufshcd_rpm_put_sync() call after the ufshcd_update_rtc()
call?
Thanks,
Bart.
More information about the Linux-mediatek
mailing list