Re: [PATCH v4] scsi: ufs: core: Don't perform UFS clkscale if host asyn scan in progress

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Fri, 2025-07-25 at 07:54 -0700, Bart Van Assche wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On 7/25/25 2:13 AM, Peter Wang (王信友) wrote:
> > Could consider luns_avail instead mutex?
> 
> That would be wrong. I think it is essential that scan_mutex is used
> in
> this patch. Additionally, the lock inversion is between devfreq->lock
> and (c->notifiers)->rwsem so it seems unlikely to me that Ziqi's
> patch
> is the patch that introduced the reported lock inversion.
> 
> Bart.


Hi Bart,

This is a complex situation involving six locks, which may result in
a circular locking dependency.
Let me explain how a new circular locking dependency is formed:

CPU0: take &(c->notifiers)->rwsem#2, wait &devfreq->lock
CPU1: take &devfreq->lock, wait &shost->scan_mutex,  <= Lock introduced
by this patch
CPU2: take &shost->scan_mutex, wait &q->sysfs_lock
CPU3: take &q->sysfs_lock, wait cpu_hotplug_lock
CPU4: take cpu_hotplug_lock, wait subsys mutex#2
CPU5: take subsys mutex#2, wait &(c->notifiers)->rwsem#2  <= Hold By
CPU0

ufshcd_add_lus triggers ufshcd_devfreq_init.
This means that clock scaling can be performed while scanning LUNs.
However, this patch adds another lock to prevent clock scaling 
before the LUN scan is complete. This is a paradoxical situation. 
If we cannnot do clock scaling before the LUN scan is complete, 
then why we start clock scaling before it?

If we don’t put it in luns_avail (start clock scaling after LUNs 
scan complete), do you have a better suggestion
for where to initialize clock scaling (ufshcd_devfreq_init)?

Thanks.
Peter