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
| ||
|
Message-ID: <366a3afc-071f-ae77-d06d-25ad750976dc@intel.com> Date: Mon, 14 Feb 2022 16:31:28 +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 12/02/2022 06:44, Kiwoong Kim wrote: >> 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); > > > Yeah.., I saw the comment but didn't get why. > > Is there anyone who knows why it's necessary for all SoCs? > At lease, I know there is no reason to forbid concurrent executions of dev cmd and power mode change. > > If there's nothing, how about adding a quick to ignore it? Is it worth it? The error handler really should have exclusive access. Have you considered, for example, races of ufshcd_reset_and restore() and dev commands, tm commands, UIC commands. I suspect more locking is needed not less.
Powered by blists - more mailing lists