linux-kernel - Re: [PATCH v2] scsi: ufs: core: Fix data race in CPU latency PM QoS request handling

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] [day] [month] [year] [list]

Message-ID: <4b970683-bc36-4dc2-a404-e1440da83ae7@acm.org>
Date: Fri, 12 Sep 2025 09:22:35 -0700
From: Bart Van Assche <bvanassche@....org>
To: Zhongqiu Han <zhongqiu.han@....qualcomm.com>, alim.akhtar@...sung.com,
 avri.altman@....com, James.Bottomley@...senPartnership.com,
 martin.petersen@...cle.com
Cc: peter.wang@...iatek.com, tanghuan@...o.com, liu.song13@....com.cn,
 quic_nguyenb@...cinc.com, viro@...iv.linux.org.uk, huobean@...il.com,
 adrian.hunter@...el.com, can.guo@....qualcomm.com, ebiggers@...nel.org,
 neil.armstrong@...aro.org, angelogioacchino.delregno@...labora.com,
 quic_narepall@...cinc.com, quic_mnaresh@...cinc.com,
 linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
 nitin.rawat@....qualcomm.com, ziqi.chen@....qualcomm.com
Subject: Re: [PATCH v2] scsi: ufs: core: Fix data race in CPU latency PM QoS
 request handling

On 9/2/25 12:48 AM, Zhongqiu Han wrote:
> -	return sysfs_emit(buf, "%d\n", hba->pm_qos_enabled);
> +	return sysfs_emit(buf, "%d\n", READ_ONCE(hba->pm_qos_enabled));

Using READ_ONCE() here is inconsistent since none of the modifications
of hba->pm_qos_enabled use WRITE_ONCE(). Protecting hba->pm_qos_enabled
modifications with a mutex is not sufficient since the above read of
hba->pm_qos_enabled is not protected by the same mutex.

Has it been considered to leave out the READ_ONCE() from the above code
and instead to add the following above the sysfs_emit() call?

guard(mutex)(&hba->pm_qos_mutex);

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 926650412eaa..98b9ce583386 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -1047,14 +1047,19 @@ EXPORT_SYMBOL_GPL(ufshcd_is_hba_active);
>    */
>   void ufshcd_pm_qos_init(struct ufs_hba *hba)
>   {
> +	mutex_lock(&hba->pm_qos_mutex);
>   
> -	if (hba->pm_qos_enabled)
> +	if (hba->pm_qos_enabled) {
> +		mutex_unlock(&hba->pm_qos_mutex);
>   		return;
> +	}
>   
>   	cpu_latency_qos_add_request(&hba->pm_qos_req, PM_QOS_DEFAULT_VALUE);
>   
>   	if (cpu_latency_qos_request_active(&hba->pm_qos_req))
>   		hba->pm_qos_enabled = true;
> +
> +	mutex_unlock(&hba->pm_qos_mutex);
>   }

Please make the above code easier to review by using
guard(mutex)(&hba->pm_qos_mutex) instead of explicit mutex_lock() and
mutex_unlock() calls.

> @@ -1063,11 +1068,16 @@ void ufshcd_pm_qos_init(struct ufs_hba *hba)
>    */
>   void ufshcd_pm_qos_exit(struct ufs_hba *hba)
>   {
> -	if (!hba->pm_qos_enabled)
> +	mutex_lock(&hba->pm_qos_mutex);
> +
> +	if (!hba->pm_qos_enabled) {
> +		mutex_unlock(&hba->pm_qos_mutex);
>   		return;
> +	}
>   
>   	cpu_latency_qos_remove_request(&hba->pm_qos_req);
>   	hba->pm_qos_enabled = false;
> +	mutex_unlock(&hba->pm_qos_mutex);
>   }

Same comment here: please make the above code easier to review by using
guard(mutex)(&hba->pm_qos_mutex) instead of explicit mutex_lock() and
mutex_unlock() calls.

> @@ -1077,10 +1087,15 @@ void ufshcd_pm_qos_exit(struct ufs_hba *hba)
>    */
>   static void ufshcd_pm_qos_update(struct ufs_hba *hba, bool on)
>   {
> -	if (!hba->pm_qos_enabled)
> +	mutex_lock(&hba->pm_qos_mutex);
> +
> +	if (!hba->pm_qos_enabled) {
> +		mutex_unlock(&hba->pm_qos_mutex);
>   		return;
> +	}
>   
>   	cpu_latency_qos_update_request(&hba->pm_qos_req, on ? 0 : PM_QOS_DEFAULT_VALUE);
> +	mutex_unlock(&hba->pm_qos_mutex);
>   }

Also in the above code, please use the guard()() macro instead of
explicit mutex_lock() and mutex_unlock() calls.

Thanks,

Bart.