From: Cristian Marussi <cristian.marussi@arm.com> To: Sudeep Holla <sudeep.holla@arm.com> Cc: Dan Carpenter <dan.carpenter@oracle.com>, "Jon Medhurst (Tixy)" <tixy@linaro.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug Date: Thu, 22 Apr 2021 12:34:52 +0100 [thread overview] Message-ID: <20210422113451.GG43717@e120937-lin> (raw) In-Reply-To: <20210422101709.GF43717@e120937-lin> On Thu, Apr 22, 2021 at 11:17:09AM +0100, Cristian Marussi wrote: > Hi, > > On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote: > > How type promotion works in ternary expressions is a bit tricky. > > The problem is that scpi_clk_get_val() returns longs, "ret" is a int > > which holds a negative error code, and le32_to_cpu() is an unsigned int. > > We want the negative error code to be cast to a negative long. But > > because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and > > becomes a high positive and then it is promoted to long and it is still > > a high positive value. > > > > Fix this by getting rid of the ternary. > > I wonder how/if the callers up in the stack check/expect ever effectively for a > 2-complement negative value inside the returned unsigned long...given that this > plugs finally into CLK framework struct clk_ops.recalc_rate via clk-scpi.c which > also expects unsigned long....but that's another story. > > FWIW regarding this patch: > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> > > Thanks > > Cristian @Sudeep, as a second though, looking at .recalc_rate() definition inside include/linux/clk-provider.h:struct clk_ops which is the direct caller of this SCPI clk function, I wonder if, instead, on error we should not return here just ZERO as the returned clock rate value as in: if (ret) return 0; given that the error code returned inside the unsigned long won't be ever considerd as such apparently, so not sure if it'd be worst to return a very big fake value or zero... Thanks Cristian > > > > Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > --- > > drivers/firmware/arm_scpi.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c > > index d0dee37ad522..3bf61854121d 100644 > > --- a/drivers/firmware/arm_scpi.c > > +++ b/drivers/firmware/arm_scpi.c > > @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id) > > > > ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id, > > sizeof(le_clk_id), &rate, sizeof(rate)); > > + if (ret) > > + return ret; > > > > - return ret ? ret : le32_to_cpu(rate); > > + return le32_to_cpu(rate); > > } > > > > static int scpi_clk_set_val(u16 clk_id, unsigned long rate) > > -- > > 2.30.2 > >
WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com> To: Sudeep Holla <sudeep.holla@arm.com> Cc: Dan Carpenter <dan.carpenter@oracle.com>, "Jon Medhurst (Tixy)" <tixy@linaro.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug Date: Thu, 22 Apr 2021 12:34:52 +0100 [thread overview] Message-ID: <20210422113451.GG43717@e120937-lin> (raw) In-Reply-To: <20210422101709.GF43717@e120937-lin> On Thu, Apr 22, 2021 at 11:17:09AM +0100, Cristian Marussi wrote: > Hi, > > On Thu, Apr 22, 2021 at 12:02:29PM +0300, Dan Carpenter wrote: > > How type promotion works in ternary expressions is a bit tricky. > > The problem is that scpi_clk_get_val() returns longs, "ret" is a int > > which holds a negative error code, and le32_to_cpu() is an unsigned int. > > We want the negative error code to be cast to a negative long. But > > because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and > > becomes a high positive and then it is promoted to long and it is still > > a high positive value. > > > > Fix this by getting rid of the ternary. > > I wonder how/if the callers up in the stack check/expect ever effectively for a > 2-complement negative value inside the returned unsigned long...given that this > plugs finally into CLK framework struct clk_ops.recalc_rate via clk-scpi.c which > also expects unsigned long....but that's another story. > > FWIW regarding this patch: > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> > > Thanks > > Cristian @Sudeep, as a second though, looking at .recalc_rate() definition inside include/linux/clk-provider.h:struct clk_ops which is the direct caller of this SCPI clk function, I wonder if, instead, on error we should not return here just ZERO as the returned clock rate value as in: if (ret) return 0; given that the error code returned inside the unsigned long won't be ever considerd as such apparently, so not sure if it'd be worst to return a very big fake value or zero... Thanks Cristian > > > > Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > > --- > > drivers/firmware/arm_scpi.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c > > index d0dee37ad522..3bf61854121d 100644 > > --- a/drivers/firmware/arm_scpi.c > > +++ b/drivers/firmware/arm_scpi.c > > @@ -552,8 +552,10 @@ static unsigned long scpi_clk_get_val(u16 clk_id) > > > > ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id, > > sizeof(le_clk_id), &rate, sizeof(rate)); > > + if (ret) > > + return ret; > > > > - return ret ? ret : le32_to_cpu(rate); > > + return le32_to_cpu(rate); > > } > > > > static int scpi_clk_set_val(u16 clk_id, unsigned long rate) > > -- > > 2.30.2 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-04-22 11:34 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-22 9:02 [PATCH] firmware: arm_scpi: prevent ternary sign expansion bug Dan Carpenter 2021-04-22 9:02 ` Dan Carpenter 2021-04-22 10:17 ` Cristian Marussi 2021-04-22 10:17 ` Cristian Marussi 2021-04-22 11:34 ` Cristian Marussi [this message] 2021-04-22 11:34 ` Cristian Marussi 2021-04-22 17:46 ` Sudeep Holla 2021-04-22 17:46 ` Sudeep Holla 2021-04-24 6:43 ` Dan Carpenter 2021-04-24 6:43 ` Dan Carpenter 2021-04-28 10:03 ` Sudeep Holla 2021-04-28 10:03 ` Sudeep Holla
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=20210422113451.GG43717@e120937-lin \ --to=cristian.marussi@arm.com \ --cc=dan.carpenter@oracle.com \ --cc=kernel-janitors@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=sudeep.holla@arm.com \ --cc=tixy@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: linkBe 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.