Re: [PATCH v2] ufs: core: fix lockdep warning of clk_scaling_lock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bart,

On 7/26/22 12:56 AM, Bart Van Assche wrote:
On 7/24/22 21:30, peter.wang@xxxxxxxxxxxx wrote:
From: Peter Wang <peter.wang@xxxxxxxxxxxx>

There have a lockdep warning like below in current flow.
kworker/u16:0:  Possible unsafe locking scenario:

kworker/u16:0:        CPU0                    CPU1
kworker/u16:0:        ----                    ----
kworker/u16:0:   lock(&hba->clk_scaling_lock);
kworker/u16:0: lock(&hba->dev_cmd.lock);
kworker/u16:0: lock(&hba->clk_scaling_lock);
kworker/u16:0:   lock(&hba->dev_cmd.lock);
kworker/u16:0:

Before this patch clk_scaling_lock was held in reader mode during the ufshcd_wb_toggle() call. With this patch applied clk_scaling_lock is not held while ufshcd_wb_toggle() is called.

This is safe because ufshcd_wb_toggle will held clk_scaling_lock in reader mode "again" in flow ufshcd_wb_toggle -> __ufshcd_wb_toggle -> ufshcd_query_flag_retry -> ufshcd_query_flag ->
ufshcd_exec_dev_cmd -> down_read(&hba->clk_scaling_lock);
The protect should enough and make sure clock is not change while send command.

Since this is a bug fix, please add a Fixes: tag.

Will add Fixes: tag in next version.


  out_unprepare:
-    ufshcd_clock_scaling_unprepare(hba, is_writelock);
+    ufshcd_clock_scaling_unprepare(hba);
+
+    /* Enable Write Booster if we have scaled up else disable it */
+    if (wb_toggle)
+        ufshcd_wb_toggle(hba, scale_up);
+
      return ret;
  }

Can the above patch can have the following unwanted effect?
* ufshcd_devfreq_scale() calls ufshcd_clock_scaling_unprepare().
* Clock scaling to a lower frequency happens.
* ufshcd_wb_toggle() enables the write booster.

Shouldn't the above ufshcd_wb_toggle() call be surrounded by down_read() and up_read() calls in addition to a check whether the WriteBooster really should be enabled instead of using 'scale_up'?

Thanks,

Bart.


You means ufshcd_devfreq_scale may have racing in two thread, right?
Then yes, it may have this unwanted effect in this condition.
But ufshcd_wb_toggle should not hold clk_scaling_lock, or the deadlock may happen. I will change this patch to protect ufshcd_devfreq_scale racing and ufshcd_wb_toggle in next version.

Thanks.
Peter







[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux