From: Bart Van Assche <bvanassche@acm.org>
To: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>,
alim.akhtar@samsung.com, avri.altman@wdc.com,
James.Bottomley@HansenPartnership.com,
martin.petersen@oracle.com
Cc: peter.wang@mediatek.com, tanghuan@vivo.com,
liu.song13@zte.com.cn, quic_nguyenb@quicinc.com,
viro@zeniv.linux.org.uk, huobean@gmail.com,
adrian.hunter@intel.com, can.guo@oss.qualcomm.com,
ebiggers@kernel.org, neil.armstrong@linaro.org,
angelogioacchino.delregno@collabora.com,
quic_narepall@quicinc.com, quic_mnaresh@quicinc.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
nitin.rawat@oss.qualcomm.com, ziqi.chen@oss.qualcomm.com
Subject: Re: [PATCH v2] scsi: ufs: core: Fix data race in CPU latency PM QoS request handling
Date: Fri, 12 Sep 2025 09:22:35 -0700 [thread overview]
Message-ID: <4b970683-bc36-4dc2-a404-e1440da83ae7@acm.org> (raw)
In-Reply-To: <20250902074829.657343-1-zhongqiu.han@oss.qualcomm.com>
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.
next prev parent reply other threads:[~2025-09-12 16:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 7:48 [PATCH v2] scsi: ufs: core: Fix data race in CPU latency PM QoS request handling Zhongqiu Han
2025-09-02 12:39 ` Peter Wang (王信友)
2025-09-03 7:10 ` Zhongqiu Han
2025-09-11 6:56 ` Zhongqiu Han
2025-09-12 16:22 ` Bart Van Assche [this message]
2025-09-15 11:45 ` Zhongqiu Han
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b970683-bc36-4dc2-a404-e1440da83ae7@acm.org \
--to=bvanassche@acm.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=adrian.hunter@intel.com \
--cc=alim.akhtar@samsung.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=avri.altman@wdc.com \
--cc=can.guo@oss.qualcomm.com \
--cc=ebiggers@kernel.org \
--cc=huobean@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=liu.song13@zte.com.cn \
--cc=martin.petersen@oracle.com \
--cc=neil.armstrong@linaro.org \
--cc=nitin.rawat@oss.qualcomm.com \
--cc=peter.wang@mediatek.com \
--cc=quic_mnaresh@quicinc.com \
--cc=quic_narepall@quicinc.com \
--cc=quic_nguyenb@quicinc.com \
--cc=tanghuan@vivo.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zhongqiu.han@oss.qualcomm.com \
--cc=ziqi.chen@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.