Re: [PATCH v3 50/57] scsi: ufs: Enable lock context analysis
[email protected] Thu, 30 Jul 2026 23:19:09 +0000
| Newsgroups | org.kernel.vger.linux-scsi |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: Pre-existing issues: - [High] ufshcd_wait_for_pending_cmds() uses io_schedule_timeout() without = setting current->state, causing a busy loop instead of sleeping. -- --- Patch [50]: [PATCH v3 50/57] scsi: ufs: Enable lock context analysis --- commit 8185dd4bd8104528b9c4d31b079a63ef3f632638 Author: Bart Van Assche <[email protected]> scsi: ufs: Enable lock context analysis This commit annotates functions that modify the state of a synchronization object to enable lock context analysis. It also removes struct semaphore annotations because lock context annotations are not supported for semaphores. > diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c > index f85582287d14d..22a5f8e9af913 100644 > --- a/drivers/ufs/core/ufshcd.c > +++ b/drivers/ufs/core/ufshcd.c > @@ -1353,6 +1353,8 @@ static int ufshcd_wait_for_pending_cmds(struct ufs_= hba *hba, [Severity: High] This is a pre-existing issue, but does ufshcd_wait_for_pending_cmds() busy loop here instead of sleeping? Looking at ufshcd_wait_for_pending_cmds(), it calls io_schedule_timeout() without first setting the task state to TASK_UNINTERRUPTIBLE: drivers/ufs/core/ufshcd.c:ufshcd_wait_for_pending_cmds() { ... do { tm_doorbell =3D ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL); tr_pending =3D ufshcd_pending_cmds(hba); if (!tm_doorbell && !tr_pending) { timeout =3D false; break; } else if (do_last_check) { break; } io_schedule_timeout(msecs_to_jiffies(20)); if (ktime_to_us(ktime_sub(ktime_get(), start)) > wait_timeout_us) { ... } Because the task state remains TASK_RUNNING, does the underlying schedule_timeout() function return immediately without yielding the CPU?=20 Could this cause severe performance degradation by hogging 100% of a CPU core and aggressively polling MMIO registers for up to 1 second during operations like UFS hardware clock scaling? > * On failure, all acquired locks are released and the tagset is unquies= ced. > */ > int ufshcd_pause_command_processing(struct ufs_hba *hba, u64 timeout_us) > + __cond_acquires(0, &hba->host->scan_mutex) > + __cond_acquires(0, &hba->clk_scaling_lock) > { > int ret =3D 0; --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/cover.1785451174.gi= [email protected]?part=3D50