linux-kernel - Re: [PATCH v1] scsi: ufs: remove clk_scaling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f2938f7-2a9e-60e8-5237-fe7ebc3b4296@intel.com>
Date:   Fri, 11 Feb 2022 14:15:10 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Kiwoong Kim <kwmad.kim@...sung.com>,
        'Avri Altman' <Avri.Altman@....com>,
        linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
        alim.akhtar@...sung.com, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, beanhuo@...ron.com,
        cang@...eaurora.org, sc.suh@...sung.com, hy50.seo@...sung.com,
        sh425.lee@...sung.com, bhoon95.kim@...sung.com,
        vkumar.1997@...sung.com
Subject: Re: [PATCH v1] scsi: ufs: remove clk_scaling_lock when clkscaling
 isn't supported.

On 11/02/2022 04:15, Kiwoong Kim wrote:
>>> I think it looks hardware specific.
>>> If the feature isn't supported, I think there is no reasonto prevent
>>> from
>>                                                                                          ^^^
>> reason to
>>
>>> running other functions, such as ufshcd_queuecommand and
>> It is no longer used in queuecommand since 5675c381ea51 and 8d077ede48c1
> 
> Yeah, you're right. It's just an example. I just want to tell that the lock also protects things that are not related with clk scaling directly.
> 
>>
>>> ufshcd_exec_dev_cmd, concurrently.
>>>
>>> So I add a condition at some points protecting with clk_scaling_lock.
>> But you still need a way to serialize device management commands.
>>
>> Thanks,
>> Avri
> 
> The dev cmd execution period is protected by mutex.
> And actual ringing a doorbell is protected by spin lock.
> 
> Is there another reason to need clk_scaling_lock even with it?
> 

The error handler really should have exclusive access.  One
of the places you change does explain that:

 		 * Hold the scaling lock just in case dev cmds
 		 * are sent via bsg and/or sysfs.
 		 */
-		down_write(&hba->clk_scaling_lock);
+		if (ufshcd_is_clkscaling_supported(hba))
+			down_write(&hba->clk_scaling_lock);