Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp265581pxf; Thu, 11 Mar 2021 03:27:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJymzbNGuKq0Lc2EwDK/P1S9E/6d6XdUfcKVsUGF21pLI00c6yzjHREBVq2MEJr5fIW9SQ4T X-Received: by 2002:a17:906:128e:: with SMTP id k14mr2514376ejb.427.1615462033419; Thu, 11 Mar 2021 03:27:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615462033; cv=none; d=google.com; s=arc-20160816; b=CtBmatof+saRj6amxEpse2Y1/JEsVehmmc/zEJbInoj7FiWrtLd3Zf6ohcH0VWZ0Gg ij2GtIvnw6z/i5vq23zo5L+a6Ka7OlYtfT4+0WKqHQXURXwVNPrl0ZBuFTdBX2G7ogMh 7KuQJgIVfO0zwGNnkTqWpEIgw27EPSYUH1wPFTJzxfiz8b/z16Rukt67sYb0shHlICU3 IbKLiLgKYISS5Ty+vLbFC2I7c2GFAnFsKgdsQY8fa+0sF1thPrO4gKR6mqGGmv8LlgfS It4DdCuxjXJydVwz2bx0jwcYuyqPGNn0XPwYinYj8WgwRZz2udOd/SZAZCf6Rt07kjnR FlGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=JbkzfNYSEA8agj9HF6mMWuX5WAU+kuMTGEc9vzTnwbY=; b=r36FSf7yeG08v/lBlZ/vsYfmY8xEnvMoZmtPei6wkbgF3OtKMQq/bv6ZU1POkM9L91 2+aYlLgCX8HoPvYZeV1CJUFYm8mIgZS3WNpszbdxlcZyOPYTGR1aL9oE5VTwRmsTs7+S WqYcCE8M1F8S/Gi2v2mD81519NMNTOBpiOJFEZwZqwJMzFySWX85Y4Vi0/LOYoYPLbte OxFCqi1hq1Wx+GkFD5pb2Efxz4JC32hCvJRNUBQTVJbB7dBnx6GrcNh7NV8aEtAOCV1z Z0c2Qh+D1fKBZ6GrsiF7sPbPux0/r5CAtVxYgSECQbaybqDDx/jgBUQ+i3Ivs0gCjljw Fv/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b24si1500009edr.415.2021.03.11.03.26.50; Thu, 11 Mar 2021 03:27:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232537AbhCKLZY (ORCPT + 99 others); Thu, 11 Mar 2021 06:25:24 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:55150 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232619AbhCKLY4 (ORCPT ); Thu, 11 Mar 2021 06:24:56 -0500 Received: from 1.general.cking.uk.vpn ([10.172.193.212]) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lKJR1-00029h-JR; Thu, 11 Mar 2021 11:24:55 +0000 Subject: Re: pinctrl: core: Handling pinmux and pinconf separately To: Michal Simek Cc: Linus Walleij , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <5c08bd61-688f-e95b-5fa3-584f190ed4bf@xilinx.com> From: Colin Ian King Message-ID: Date: Thu, 11 Mar 2021 11:24:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <5c08bd61-688f-e95b-5fa3-584f190ed4bf@xilinx.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/03/2021 11:16, Michal Simek wrote: > > > On 3/11/21 11:57 AM, Colin Ian King wrote: >> Hi, >> >> Static analysis on linux-next with Coverity has found a potential issue >> in drivers/pinctrl/core.c with the following commit: >> >> commit 0952b7ec1614abf232e921aac0cc2bca8e60e162 >> Author: Michal Simek >> Date: Wed Mar 10 09:16:54 2021 +0100 >> >> pinctrl: core: Handling pinmux and pinconf separately >> >> The analysis is as follows: >> >> 1234 /** >> 1235 * pinctrl_commit_state() - select/activate/program a pinctrl state >> to HW >> 1236 * @p: the pinctrl handle for the device that requests configuration >> 1237 * @state: the state handle to select/activate/program >> 1238 */ >> 1239 static int pinctrl_commit_state(struct pinctrl *p, struct >> pinctrl_state *state) >> 1240 { >> 1241 struct pinctrl_setting *setting, *setting2; >> 1242 struct pinctrl_state *old_state = p->state; >> >> 1. var_decl: Declaring variable ret without initializer. >> >> 1243 int ret; >> 1244 >> >> 2. Condition p->state, taking true branch. >> >> 1245 if (p->state) { >> 1246 /* >> 1247 * For each pinmux setting in the old state, forget >> SW's record >> 1248 * of mux owner for that pingroup. Any pingroups >> which are >> 1249 * still owned by the new state will be re-acquired >> by the call >> 1250 * to pinmux_enable_setting() in the loop below. >> 1251 */ >> >> 3. Condition 0 /* !!(!__builtin_types_compatible_p() && >> !__builtin_types_compatible_p()) */, taking false branch. >> 4. Condition !(&setting->node == &p->state->settings), taking true >> branch. >> 7. Condition 0 /* !!(!__builtin_types_compatible_p() && >> !__builtin_types_compatible_p()) */, taking false branch. >> 8. Condition !(&setting->node == &p->state->settings), taking true >> branch. >> 11. Condition 0 /* !!(!__builtin_types_compatible_p() && >> !__builtin_types_compatible_p()) */, taking false branch. >> 12. Condition !(&setting->node == &p->state->settings), taking false >> branch. >> >> 1252 list_for_each_entry(setting, &p->state->settings, >> node) { >> >> 5. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true >> branch. >> 9. Condition setting->type != PIN_MAP_TYPE_MUX_GROUP, taking true >> branch. >> 1253 if (setting->type != PIN_MAP_TYPE_MUX_GROUP) >> 6. Continuing loop. >> 10. Continuing loop. >> >> 1254 continue; >> 1255 pinmux_disable_setting(setting); >> 1256 } >> 1257 } >> 1258 >> 1259 p->state = NULL; >> 1260 >> 1261 /* Apply all the settings for the new state - pinmux first */ >> >> 13. Condition 0 /* !!(!__builtin_types_compatible_p() && >> !__builtin_types_compatible_p()) */, taking false branch. >> 14. Condition !(&setting->node == &state->settings), taking true branch. >> 1262 list_for_each_entry(setting, &state->settings, node) { >> 15. Switch case value PIN_MAP_TYPE_CONFIGS_PIN. >> >> 1263 switch (setting->type) { >> 1264 case PIN_MAP_TYPE_MUX_GROUP: >> 1265 ret = pinmux_enable_setting(setting); >> 1266 break; >> 1267 case PIN_MAP_TYPE_CONFIGS_PIN: >> 1268 case PIN_MAP_TYPE_CONFIGS_GROUP: >> >> 16. Breaking from switch. >> >> 1269 break; >> 1270 default: >> 1271 ret = -EINVAL; >> 1272 break; >> 1273 } >> 1274 >> >> Uninitialized scalar variable (UNINIT) >> 17. uninit_use: Using uninitialized value ret. >> >> 1275 if (ret < 0) >> 1276 goto unapply_new_state; >> >> For the PIN_MAP_TYPE_CONFIGS_PIN and PIN_MAP_TYPE_CONFIGS_GROUP >> setting->type cases the loop can break out with ret not being set. Since >> ret has not been initialized it the ret < 0 check is checking against an >> uninitialized value. >> >> I was not sure if the PIN_MAP_TYPE_CONFIGS_PIN and >> PIN_MAP_TYPE_CONFIGS_GROUP cases should be setting ret and if so, what >> the value of ret should be set to (is it an error condition or not?). Or >> should ret be initialized to 0 or a default error value at the start of >> the function. >> >> Hence I'm reporting this issue. > > What about this? Is this passing static analysis? It will take me 2 hours to re-run the analysis, but from eyeballing the code I think the assignments will fix this. Colin > > diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c > index f5c32d2a3c91..136c323d855e 100644 > --- a/drivers/pinctrl/core.c > +++ b/drivers/pinctrl/core.c > @@ -1266,6 +1266,7 @@ static int pinctrl_commit_state(struct pinctrl *p, > struct pinctrl_state *state) > break; > case PIN_MAP_TYPE_CONFIGS_PIN: > case PIN_MAP_TYPE_CONFIGS_GROUP: > + ret = 0; > break; > default: > ret = -EINVAL; > @@ -1284,6 +1285,7 @@ static int pinctrl_commit_state(struct pinctrl *p, > struct pinctrl_state *state) > list_for_each_entry(setting, &state->settings, node) { > switch (setting->type) { > case PIN_MAP_TYPE_MUX_GROUP: > + ret = 0; > break; > case PIN_MAP_TYPE_CONFIGS_PIN: > case PIN_MAP_TYPE_CONFIGS_GROUP: > > Thanks, > Michal >