All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] firmware: arm_scmi: avoid returning uninialized data
Date: Fri, 16 Feb 2024 17:21:02 +0000	[thread overview]
Message-ID: <Zc-ZfgVbAvAZVrPu@pluto> (raw)
In-Reply-To: <20240216163259.1927967-1-arnd@kernel.org>

On Fri, Feb 16, 2024 at 05:32:53PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Clang notices that there is a code path through
> scmi_powercap_notify_supported() that returns an
> undefined value:
> 

Hi Arnd,

> drivers/firmware/arm_scmi/powercap.c:821:11: error: variable 'supported' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>   821 |         else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/firmware/arm_scmi/powercap.c:824:9: note: uninitialized use occurs here
>   824 |         return supported;
>       |                ^~~~~~~~~
> drivers/firmware/arm_scmi/powercap.c:821:7: note: remove the 'if' if its condition is always true
>   821 |         else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   822 |                 supported = dom_info->notify_powercap_measurement_change;
> drivers/firmware/arm_scmi/powercap.c:811:16: note: initialize the variable 'supported' to silence this warning
>   811 |         bool supported;
>       |                       ^
> 
> Return 'false' here, which is probably what was intended.
> 
> Fixes: c92a75fe84ce ("firmware: arm_scmi: Implement Powercap .is_notify_supported callback")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

thanks for looking at this, this series that I've just posted is still
to be reviewd at all, so I would expect issues :D...BUT in this case I
dont think that the clang report is valid since, inside the culprit
function scmi_powercap_notify_supported(), a few lines before the
reported usage of unitialized data there is a check (@line 816) on the
'bounds' of evt_id itself

	if (evt_id >= ARRAY_SIZE(evt_2_cmd) || src_id >= pi->num_domains)
		return false;

so basically the mentioned if/else WILL be evaluated in some of its
branches for sure and supported wont be uninitialized.

Indeed, I removed from here (and from all the series) the explicit
initialization at definition time right before posting the series.

Having saidm that...maybe it is just brain-dead this approach of mine
since it is able to fool clang & friends...I would add bACK an explicit
initialization of supported all across this series in V2, if this
sounds good to you.

Thanks,
Cristian


> ---
>  drivers/firmware/arm_scmi/powercap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/firmware/arm_scmi/powercap.c b/drivers/firmware/arm_scmi/powercap.c
> index aae91f47303e..8ee3be8776b0 100644
> --- a/drivers/firmware/arm_scmi/powercap.c
> +++ b/drivers/firmware/arm_scmi/powercap.c
> @@ -820,6 +820,8 @@ scmi_powercap_notify_supported(const struct scmi_protocol_handle *ph,
>  		supported = dom_info->notify_powercap_cap_change;
>  	else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>  		supported = dom_info->notify_powercap_measurement_change;
> +	else
> +		supported = false;
>  
>  	return supported;
>  }
> -- 
> 2.39.2
> 

WARNING: multiple messages have this Message-ID (diff)
From: Cristian Marussi <cristian.marussi@arm.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] firmware: arm_scmi: avoid returning uninialized data
Date: Fri, 16 Feb 2024 17:21:02 +0000	[thread overview]
Message-ID: <Zc-ZfgVbAvAZVrPu@pluto> (raw)
In-Reply-To: <20240216163259.1927967-1-arnd@kernel.org>

On Fri, Feb 16, 2024 at 05:32:53PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Clang notices that there is a code path through
> scmi_powercap_notify_supported() that returns an
> undefined value:
> 

Hi Arnd,

> drivers/firmware/arm_scmi/powercap.c:821:11: error: variable 'supported' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>   821 |         else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/firmware/arm_scmi/powercap.c:824:9: note: uninitialized use occurs here
>   824 |         return supported;
>       |                ^~~~~~~~~
> drivers/firmware/arm_scmi/powercap.c:821:7: note: remove the 'if' if its condition is always true
>   821 |         else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   822 |                 supported = dom_info->notify_powercap_measurement_change;
> drivers/firmware/arm_scmi/powercap.c:811:16: note: initialize the variable 'supported' to silence this warning
>   811 |         bool supported;
>       |                       ^
> 
> Return 'false' here, which is probably what was intended.
> 
> Fixes: c92a75fe84ce ("firmware: arm_scmi: Implement Powercap .is_notify_supported callback")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

thanks for looking at this, this series that I've just posted is still
to be reviewd at all, so I would expect issues :D...BUT in this case I
dont think that the clang report is valid since, inside the culprit
function scmi_powercap_notify_supported(), a few lines before the
reported usage of unitialized data there is a check (@line 816) on the
'bounds' of evt_id itself

	if (evt_id >= ARRAY_SIZE(evt_2_cmd) || src_id >= pi->num_domains)
		return false;

so basically the mentioned if/else WILL be evaluated in some of its
branches for sure and supported wont be uninitialized.

Indeed, I removed from here (and from all the series) the explicit
initialization at definition time right before posting the series.

Having saidm that...maybe it is just brain-dead this approach of mine
since it is able to fool clang & friends...I would add bACK an explicit
initialization of supported all across this series in V2, if this
sounds good to you.

Thanks,
Cristian


> ---
>  drivers/firmware/arm_scmi/powercap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/firmware/arm_scmi/powercap.c b/drivers/firmware/arm_scmi/powercap.c
> index aae91f47303e..8ee3be8776b0 100644
> --- a/drivers/firmware/arm_scmi/powercap.c
> +++ b/drivers/firmware/arm_scmi/powercap.c
> @@ -820,6 +820,8 @@ scmi_powercap_notify_supported(const struct scmi_protocol_handle *ph,
>  		supported = dom_info->notify_powercap_cap_change;
>  	else if (evt_id == SCMI_EVENT_POWERCAP_MEASUREMENTS_CHANGED)
>  		supported = dom_info->notify_powercap_measurement_change;
> +	else
> +		supported = false;
>  
>  	return supported;
>  }
> -- 
> 2.39.2
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-02-16 17:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-16 16:32 [PATCH] firmware: arm_scmi: avoid returning uninialized data Arnd Bergmann
2024-02-16 16:32 ` Arnd Bergmann
2024-02-16 17:21 ` Cristian Marussi [this message]
2024-02-16 17:21   ` Cristian Marussi
2024-02-16 20:19   ` Arnd Bergmann
2024-02-16 20:19     ` Arnd Bergmann

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=Zc-ZfgVbAvAZVrPu@pluto \
    --to=cristian.marussi@arm.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=justinstitt@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=sudeep.holla@arm.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.