Message ID | 20240216163259.1927967-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp632193dyb; Fri, 16 Feb 2024 08:33:20 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXvWdekW7sh78oXauuvCBEkszGRpnwv6MI1Ypbef+/cePfENRIwUeI2EQgokESkzKwM4ETT8mQAPxsLwhhsgl7xeO+TnQ== X-Google-Smtp-Source: AGHT+IFJShdCp5DoZK1eFN1WEjVuPqTwXwX6g0Zdnqkbs0cDHOR+PXstvn8Lv2vgBCEBDlMfkzWv X-Received: by 2002:ac8:5814:0:b0:42d:b6c5:d192 with SMTP id g20-20020ac85814000000b0042db6c5d192mr6708835qtg.15.1708101200259; Fri, 16 Feb 2024 08:33:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708101200; cv=pass; d=google.com; s=arc-20160816; b=nhKnIAVk9eso4/TLG4XVSufYZhHj7dzN4evlR0RamvGhEouUfXfFm6SXqRba7YE7ku 0eH3ROQx9+FF5L3bRzwv2JDxg1AHArrWaYsoL8kmHEDZCFCwhwjQSrlQwG/gclm8ynut G1/6OX8KIBvgvBZvwCTjH0zxEpM+yUvejcNM3nX4Aq4h2sJOzaBUNncabwIcqBpeEHkE UJKhzadcvc5AaGDrhYxTawQwevywgDK2OYGQLi94b2szyO7frKgc30HjoRgLEyrlG6vL BsxYso8nUYvyAQlhRrgllKIt/+F9VPTpgyktXzCpmVpsOu603b73IO7xS4I98EzPDuFn 1ezA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=b5DSmSd4K+oWLCHRGssM6CQ2CeYy3hkNS3+qbqaNMiQ=; fh=ESukiek5XBcxYukSNwhmiZeCgQUwgaH4yRguuhSV0iQ=; b=nFHnTCdRc0n/mC3UZdpXOhgNvtTVXUui0ygEvJP7jWvxVRudtw5iRCbJC0yLvCllpp smBDoSkZeIMucx+DwvExwIcyjt+dQ6dT8TC4lYOKmkkHZZSIOyJZO6O2DyriVPgjkLrv 5Vqgam9lpR9H215tviBT9I5gSImi8K1C9RqIpOZXLH8fKT5Ddt0wF3qCWLIzyOYIMMKD JmO8wqSaDlCpyCl8nDjHHngszhkodqEn5N3n80ZVY/w8xGfj+hjJkGSP09V+L1xANiCQ peHHr0vC1DnQIc9qw66o6JZsqI/zwxkN0JgQtdai6oLZlH0jf8jSZNKTS+gGGRVLnTBx pBDg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CCt+eSyw; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id j3-20020ac85f83000000b0042dacda1b93si181559qta.492.2024.02.16.08.33.20 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 08:33:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CCt+eSyw; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-68962-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0EB881C218B8 for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 16:33:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 51B48130ADD; Fri, 16 Feb 2024 16:33:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CCt+eSyw" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE75944369; Fri, 16 Feb 2024 16:33:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708101184; cv=none; b=YqmJJbz3Rspe1XnKfsdI0AMrr/70ZVFt3IOrPv8Mj7iW9KBQVaZyUBHcb3Tbdg4Wth73m8Z75MDj935AEsTYrCWBR7RgWs1foIB+TaPtqajs/GsWcEAzXlMX77++11jtfiwaZlEPyAok1ThjtZvVUcH6oMgzBC9f8UKAK1vKwYg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708101184; c=relaxed/simple; bh=Of7v1GxhPAmcslNCv2upPf4LImqPPOW1O8gZ/gUB0K0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Ki5ahlPr5++u5/THDLzyqZ6ORUb4vPXRwWmrxAs/ZqIL/ZqNlP9PT4GPG24dXhSHH2ORUP12LObN3Z499fGGXuCJ20ZiWuLP4aYecedWg7BTiyXETNeLQOoPFe2+Yob8qCo6HBLVPWD4w3zYMa/icZ5Bkt51b3QW3HgsNIOJGjI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CCt+eSyw; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 063E8C433F1; Fri, 16 Feb 2024 16:33:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708101184; bh=Of7v1GxhPAmcslNCv2upPf4LImqPPOW1O8gZ/gUB0K0=; h=From:To:Cc:Subject:Date:From; b=CCt+eSywPtfHMHf159xCuj+SEArQm0vinZXB6BlnoVBqEYpD8oB39RXX/hgLEHvQ6 8Rb/uYvmOTcCclLOSkiWIKKM2Ej3gutNnqUMK2l5YHCw35HAQgkHAKWFFuE2988sS6 WpbEean1hiftDBiGRvTDLCVq20o5L5C9ajE8+ttVRzE2keG2Dkns3Nyi1Z0xqd8uT3 4Jocxw6KCYxdzZ+Uae58DbpQLhsBwjISLfai3uErE8cN/lq2vU9feE/vhoPzmLNtHK /TkwduhA77vJ4pv8CsOe4UYULsp04ut6lWK5lJj0f5ZLaOe6g6pKhmOOLI4aEcmtTM wpdK7UrXHZOMg== From: Arnd Bergmann <arnd@kernel.org> To: Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com> Cc: 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: [PATCH] firmware: arm_scmi: avoid returning uninialized data Date: Fri, 16 Feb 2024 17:32:53 +0100 Message-Id: <20240216163259.1927967-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791073923847911392 X-GMAIL-MSGID: 1791073923847911392 |
Series |
firmware: arm_scmi: avoid returning uninialized data
|
|
Commit Message
Arnd Bergmann
Feb. 16, 2024, 4:32 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> Clang notices that there is a code path through scmi_powercap_notify_supported() that returns an undefined value: 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> --- drivers/firmware/arm_scmi/powercap.c | 2 ++ 1 file changed, 2 insertions(+)
Comments
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; }