From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
linux-doc@vger.kernel.org
Cc: sudeep.holla@kernel.org, james.quinlan@broadcom.com,
f.fainelli@gmail.com, vincent.guittot@linaro.org,
etienne.carriere@st.com, peng.fan@oss.nxp.com,
michal.simek@amd.com, d-gole@ti.com, jic23@kernel.org,
elif.topuz@arm.com, lukasz.luba@arm.com, philip.radford@arm.com,
souvik.chakravarty@arm.com, leitao@kernel.org, kas@kernel.org,
puranjay@kernel.org, usama.arif@linux.dev, kernel-team@meta.com,
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Subject: Re: [PATCH v12 03/25] firmware: arm_scmi: Introduce protocol instance notifiers
Date: Tue, 22 Sep 2026 15:44:48 +0200 [thread overview]
Message-ID: <c80354c7-0153-4a82-a9a1-9e2fd2929449@kernel.org> (raw)
In-Reply-To: <20260920091928.2014972-4-cristian.marussi@arm.com>
On 9/20/26 11:19, Cristian Marussi wrote:
> SCMI Protocol notifications are typically used by SCMI drivers to detect
> and react to particular conditions: this was the assumption and the classic
> usage scenario upon which the SCMI notification framework was built.
Was the paragraph supposed to start with "SCMI notifications" ? Because later
you describe how some protocols might want to reuse the "existing SCMI
Notifications machinery", and here you talk about the traditional usage.
> - mutex_lock(&info->protocols_mtx);
> - pi = idr_find(&info->protocols, protocol_id);
> + scoped_guard(mutex, &info->protocols_mtx) {
> + pi = idr_find(&info->protocols, protocol_id);
> + if (pi) {
> + refcount_inc(&pi->users);
> + } else {
> + const struct scmi_protocol *proto;
>
> - if (pi) {
> - refcount_inc(&pi->users);
> - } else {
> - const struct scmi_protocol *proto;
> + /* Fails if protocol not registered on bus */
> + proto = scmi_protocol_get(protocol_id, &info->version);
> + if (!proto)
> + return ERR_PTR(-EPROBE_DEFER);
>
> - /* Fails if protocol not registered on bus */
> - proto = scmi_protocol_get(protocol_id, &info->version);
> - if (proto)
> pi = scmi_alloc_init_protocol_instance(info, proto);
> - else
> - pi = ERR_PTR(-EPROBE_DEFER);
> + if (IS_ERR(pi))
> + return pi;
> +
> + proto_notifier_nb = READ_ONCE(pi->pno.nb);
> + }
> + }
> +
> + if (proto_notifier_nb) {
> + if (scmi_protocol_notifier_register(pi->handle, &pi->pno))
> + dev_warn(handle->dev,
> + "Failed to register protocol notifier\n");
if (proto_notifier_nb &&
scmi_protocol_notifier_register(pi->handle, &pi->pno))
dev_warn(handle->dev, ...)
As we dropped the mutex, I assume somebody else could move ahead and
refcount_inc(&pi->users) + return before the notifier was registered? Is that
expected?
> }
> - mutex_unlock(&info->protocols_mtx);
>
> return pi;
> }
> @@ -2366,13 +2398,35 @@ int scmi_protocol_acquire(const struct scmi_handle *handle, u8 protocol_id)
> void scmi_protocol_release(const struct scmi_handle *handle, u8 protocol_id)
> {
> struct scmi_info *info = handle_to_scmi_info(handle);
> + struct notifier_block *proto_notifier_nb = NULL;
> struct scmi_protocol_instance *pi;
>
> - mutex_lock(&info->protocols_mtx);
> - pi = idr_find(&info->protocols, protocol_id);
> - if (WARN_ON(!pi))
> - goto out;
> + scoped_guard(mutex, &info->protocols_mtx) {
> + pi = idr_find(&info->protocols, protocol_id);
> + if (WARN_ON(!pi))
> + return;
>
> + /*
> + * If a protocol notifier was registered and this is the
> + * last istance releasing the protocol, mark the notifier
s/istance/instance/
> + * for un-registration: note that the notifier itself counts
> + * as one user, as for any other regular notification, so if a
> + * protocol notifier is registered and there are only 2 users
> + * active we can derive that this is the last protocol
> + * instance de-registering.
> + */
> + if (scmi_protocol_notifier_registered(&pi->pno) &&
> + refcount_read(&pi->users) == 2)
> + proto_notifier_nb = READ_ONCE(pi->pno.nb);
> + }
> +
We drop the mutex now temporarily. What happens if another instance gets
registered (incrementing &pi->users) just after we dropped the lock and
unregister the notifier?
Shouldn't we care about that or why is it ok?
--
Cheers,
David
next prev parent reply other threads:[~2026-09-22 13:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 9:19 [PATCH v12 00/25] Introduce SCMI Telemetry support Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 01/25] firmware: arm_scmi: Add new SCMIv4.0 error codes definitions Cristian Marussi
2026-09-22 12:20 ` David Hildenbrand (Arm)
2026-09-22 17:32 ` Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 02/25] firmware: arm_scmi: Allow registration of unknown-size events/reports Cristian Marussi
2026-09-22 13:15 ` David Hildenbrand (Arm)
2026-09-20 9:19 ` [PATCH v12 03/25] firmware: arm_scmi: Introduce protocol instance notifiers Cristian Marussi
2026-09-22 13:44 ` David Hildenbrand (Arm) [this message]
2026-09-20 9:19 ` [PATCH v12 04/25] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 05/25] include: trace: Add Telemetry trace events Cristian Marussi
2026-09-22 13:48 ` David Hildenbrand (Arm)
2026-09-20 9:19 ` [PATCH v12 06/25] firmware: arm_scmi: Add basic Telemetry support Cristian Marussi
2026-09-22 14:42 ` David Hildenbrand (Arm)
2026-09-20 9:19 ` [PATCH v12 07/25] firmware: arm_scmi: Add support to parse SHMTIs areas Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 08/25] firmware: arm_scmi: Add Telemetry configuration operations Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 09/25] firmware: arm_scmi: Add Telemetry DataEvent read capabilities Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 10/25] firmware: arm_scmi: Add support for Telemetry reset Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 11/25] firmware: arm_scmi: Add Telemetry notification support Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 12/25] firmware: arm_scmi: Add support for boot-on Telemetry Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 13/25] firmware: arm-scmi: Add telemetry generic event support Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 14/25] firmware: arm_scmi: Add Telemetry generation counter event Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 15/25] firmware: arm_scmi: Add common per-protocol debugfs support Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 16/25] firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 17/25] firmware: arm_scmi: Add Telemetry debugfs ABI documentation Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 18/25] firmware: arm_scmi: Expose per-instance identifier Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 19/25] firmware: arm_scmi: Add un-managed methods to get/put protocols operations Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 20/25] uapi: Add ARM SCMI Telemetry definitions Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 21/25] firmware: arm_scmi: Add System Telemetry driver Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 22/25] docs: ioctl-number: Add SCMI Ioctls Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 23/25] [RFC] Documentation: Add SCMI System Telemetry documentation Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 24/25] [RFC] tools/scmi: Add SCMI Telemetry testing tool Cristian Marussi
2026-09-20 9:19 ` [PATCH v12 25/25] [RFC] kselftest/arm64: Add SCMI Telemetry UAPI compliance testcases Cristian Marussi
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=c80354c7-0153-4a82-a9a1-9e2fd2929449@kernel.org \
--to=david@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=d-gole@ti.com \
--cc=elif.topuz@arm.com \
--cc=etienne.carriere@st.com \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=jic23@kernel.org \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=leitao@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=philip.radford@arm.com \
--cc=puranjay@kernel.org \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@kernel.org \
--cc=usama.arif@linux.dev \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®