| Message ID | 20240216163259.1927967-1-arnd@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | firmware: arm_scmi: avoid returning uninialized data | expand |
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 >
On Fri, Feb 16, 2024, at 18:21, Cristian Marussi wrote: > 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: >> > > 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. I'm fine with any solution that avoids the warning. I usually prefer the explicit assignment where it's needed over having it as part of the declaration, and in this case I would probably pick a switch/case of a set of if/else fi/else blocks Arnd
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; }