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 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.