From: Cristian Marussi <cristian.marussi@arm.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
sudeep.holla@arm.com, 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, quic_sibis@quicinc.com,
dan.carpenter@linaro.org, d-gole@ti.com,
souvik.chakravarty@arm.com
Subject: Re: [PATCH 02/10] firmware: arm_scmi: Reduce the scope of protocols mutex
Date: Tue, 21 Oct 2025 10:36:00 +0100 [thread overview]
Message-ID: <aPdUAOirD2yodeTy@pluto> (raw)
In-Reply-To: <20251017160702.00002af4@huawei.com>
On Fri, Oct 17, 2025 at 04:07:02PM +0100, Jonathan Cameron wrote:
> On Thu, 25 Sep 2025 21:35:46 +0100
> Cristian Marussi <cristian.marussi@arm.com> wrote:
>
> > Currently the mutex dedicated to the protection of the list of registered
> > protocols is held during all the protocol initialization phase.
> >
> > Such a wide locking region is not needed and causes problem when trying to
> > initialize notifications from within a protocol initialization routine.
> >
> > Reduce the scope of the protocol mutex.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>
> Hi Cristian. A few things inline and this runs into one of the things
> that is dangerous to do with guard() or the other cleanup.h magic
> (and documented there!)
Hi Jonathan,
thanks for having a look at this series.
>
> > ---
> > drivers/firmware/arm_scmi/driver.c | 53 +++++++++++++++---------------
> > 1 file changed, 26 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> > index bd56a877fdfc..71ee25b78624 100644
> > --- a/drivers/firmware/arm_scmi/driver.c
> > +++ b/drivers/firmware/arm_scmi/driver.c
> > @@ -17,6 +17,7 @@
> > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >
> > #include <linux/bitmap.h>
> > +#include <linux/cleanup.h>
> > #include <linux/debugfs.h>
> > #include <linux/device.h>
> > #include <linux/export.h>
> > @@ -2179,10 +2180,13 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
> > if (ret)
> > goto clean;
> >
> > - ret = idr_alloc(&info->protocols, pi, proto->id, proto->id + 1,
> > - GFP_KERNEL);
> > - if (ret != proto->id)
> > - goto clean;
> > + /* Finally register the initialized protocol */
> > + scoped_guard(mutex, &info->protocols_mtx) {
>
> See the guidance in cleanup.h on mixing goto and anything defined in that file.
>
> In some compilers, if you hit the goto above and hence jump over this
> the cleanup variable will still be instantiated, but not initialized leading to
> a potential attempt to unlock random memory.
>
> Either this needs more substantial rework, or just handling the mutex with
> out using guards.
>
Thanks for the heads-up I will dig better into cleanup.h which obviously
I did not enough...my bad.
>
> > + ret = idr_alloc(&info->protocols, pi, proto->id, proto->id + 1,
> > + GFP_KERNEL);
> > + if (ret != proto->id)
> > + goto clean;
> > + }
> >
> > /*
> > * Warn but ignore events registration errors since we do not want
> > @@ -2243,25 +2247,22 @@ scmi_alloc_init_protocol_instance(struct scmi_info *info,
> > static struct scmi_protocol_instance * __must_check
> > scmi_get_protocol_instance(const struct scmi_handle *handle, u8 protocol_id)
> > {
> > - struct scmi_protocol_instance *pi;
> > + struct scmi_protocol_instance *pi = ERR_PTR(-EPROBE_DEFER);
> > struct scmi_info *info = handle_to_scmi_info(handle);
> > + const struct scmi_protocol *proto;
> >
> > - mutex_lock(&info->protocols_mtx);
> > - pi = idr_find(&info->protocols, protocol_id);
> > -
> > - 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)
> > - pi = scmi_alloc_init_protocol_instance(info, proto);
> > - else
> > - pi = ERR_PTR(-EPROBE_DEFER);
> > + scoped_guard(mutex, &info->protocols_mtx) {
> > + pi = idr_find(&info->protocols, protocol_id);
> > + if (pi) {
>
> if !pi we carry on with it NULL, which is a behavior change from
> before where it would be ERR_PTR(-EPROBE_DEFER);
>
> That might not matter, but it's not 'obviously' a safe change.
You are right...also the Dox comment is obsoleted..I will review this
patch as a whole, since even if probably right in its essence is badly
implemented because I rushed it in in this series to fix a probblem that
popped up on KASAN.
>
> > + refcount_inc(&pi->users);
> > + return pi;
> > + }
> > }
> > - mutex_unlock(&info->protocols_mtx);
> > +
> > + /* Fails if protocol not registered on bus */
> > + proto = scmi_protocol_get(protocol_id, &info->version);
> > + if (proto)
> Trivial but I'd flip the logic to
> if (!proto)
> return ERR_PTR(-EPROBE_DEFER);
> assuming a NULL return as mentioned above isn't the intent.
> Then
> return scmi_alloc_init_protocol_instance(info, protoo);
Yes this seems a better rework...
Thanks,
Cristian
next prev parent reply other threads:[~2025-10-21 9:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 20:35 [PATCH 00/10] Introduce SCMI Telemetry support Cristian Marussi
2025-09-25 20:35 ` [PATCH 01/10] firmware: arm_scmi: Define a common SCMI_MAX_PROTOCOLS value Cristian Marussi
2025-09-25 20:35 ` [PATCH 02/10] firmware: arm_scmi: Reduce the scope of protocols mutex Cristian Marussi
2025-10-17 15:07 ` Jonathan Cameron
2025-10-21 9:36 ` Cristian Marussi [this message]
2025-09-25 20:35 ` [PATCH 03/10] firmware: arm_scmi: Allow protocols to register for notifications Cristian Marussi
2025-10-17 15:10 ` Jonathan Cameron
2025-10-21 9:37 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 04/10] uapi: Add ARM SCMI definitions Cristian Marussi
2025-09-26 14:30 ` kernel test robot
2025-10-17 15:14 ` Jonathan Cameron
2025-10-21 9:40 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 05/10] firmware: arm_scmi: Add Telemetry protocol support Cristian Marussi
2025-09-26 17:27 ` kernel test robot
2025-10-17 15:37 ` Jonathan Cameron
2025-10-21 10:08 ` Cristian Marussi
2025-10-28 11:43 ` Lukasz Luba
2025-10-28 17:51 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 06/10] firmware: arm_scmi: Add System Telemetry driver Cristian Marussi
2025-10-20 16:23 ` Jonathan Cameron
2025-10-21 10:27 ` Cristian Marussi
2025-10-21 15:15 ` Jonathan Cameron
2025-10-21 16:03 ` Cristian Marussi
2025-10-24 10:33 ` Jonathan Cameron
2025-09-25 20:35 ` [PATCH 07/10] firmware: arm_scmi: Add System Telemetry ioctls support Cristian Marussi
2025-10-20 16:30 ` Jonathan Cameron
2025-10-21 10:30 ` Cristian Marussi
2025-09-25 20:35 ` [PATCH 08/10] firmware: arm_scmi: Add Telemetry components view Cristian Marussi
2025-09-25 20:35 ` [PATCH 09/10] include: trace: Add Telemetry trace events Cristian Marussi
2025-09-25 20:35 ` [PATCH 10/10] firmware: arm_scmi: Use new Telemetry traces Cristian Marussi
2025-09-26 13:05 ` kernel test robot
2025-09-26 19:54 ` kernel test robot
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=aPdUAOirD2yodeTy@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=d-gole@ti.com \
--cc=dan.carpenter@linaro.org \
--cc=etienne.carriere@st.com \
--cc=f.fainelli@gmail.com \
--cc=james.quinlan@broadcom.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--cc=quic_sibis@quicinc.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).