lkml.org 
[lkml]   [2021]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] scsi: ufs: Fix a possible dead lock in clock scaling
Hi Bart,

On 2021-09-18 01:27, Bart Van Assche wrote:
> On 9/16/21 6:51 PM, Can Guo wrote:
>> Assume a scenario where task A and B call ufshcd_devfreq_scale()
>> simultaneously. After task B calls downgrade_write() [1], but before
>> it
>> calls down_read() [3], if task A calls down_write() [2], when task B
>> calls
>> down_read() [3], it will lead to dead lock.
>
> Something is wrong with the above description. The downgrade_write()
> call is
> not followed by down_read() but by up_read(). Additionally, I don't see
> how
> concurrent calls of ufshcd_devfreq_scale() could lead to a deadlock.

As mentioned in the commit msg, the down_read() [3] is from
ufshcd_wb_ctrl().

Task A -
down_write [2]
ufshcd_clock_scaling_prepare
ufshcd_devfreq_scale
ufshcd_clkscale_enable_store

Task B -
down_read [3]
ufshcd_exec_dev_cmd
ufshcd_query_flag
ufshcd_wb_ctrl
downgrade_write [1]
ufshcd_devfreq_scale
ufshcd_devfreq_target
devfreq_set_target
update_devfreq
devfreq_performance_handler
governor_store


> If one thread calls downgrade_write() and another thread calls
> down_write()
> immediately, that down_write() call will block until the other thread
> has called up_read()
> without triggering a deadlock.

Since the down_write() caller is blocked, the down_read() caller, which
comes after
down_write(), is blocked too, no? downgrade_write() keeps lock owner as
it is, but
it does not change the fact that readers and writers can be blocked by
each other.

>
> Thanks,
>
> Bart.

Thanks,

Can.

\
 
 \ /
  Last update: 2021-09-29 05:31    [W:0.102 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site