[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <18ea9fa8-93fe-f371-68ee-3d12eac252c8@canonical.com>
Date: Fri, 20 Dec 2019 00:02:08 +0000
From: Colin Ian King <colin.king@...onical.com>
To: Johannes Berg <johannes.berg@...el.com>,
Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
Luca Coelho <luciano.coelho@...el.com>,
Intel Linux Wireless <linuxwifi@...el.com>,
Kalle Valo <kvalo@...eaurora.org>,
"David S. Miller" <davem@...emloft.net>,
Ihab Zhaika <ihab.zhaika@...el.com>,
Shahar S Matityahu <shahar.s.matityahu@...el.com>,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: re: iwlwifi: refactor the SAR tables from mvm to acpi
Hi,
Static analysis with Coverity has detected a potential issue with the
following commit:
commit 39c1a9728f938c7255ce507c8d56b73e8a4ebddf
Author: Ihab Zhaika <ihab.zhaika@...el.com>
Date: Fri Nov 15 09:28:11 2019 +0200
iwlwifi: refactor the SAR tables from mvm to acpi
in function iwl_sar_get_ewrd_table() we have an array index pos being
initialized to 3 and then incremented each time a loop iterates:
for (i = 0; i < n_profiles; i++) {
/* the tables start at element 3 */
int pos = 3;
/* The EWRD profiles officially go from 2 to 4, but we
* save them in sar_profiles[1-3] (because we don't
* have profile 0). So in the array we start from 1.
*/
ret = iwl_sar_set_profile(&wifi_pkg->package.elements[pos],
&fwrt->sar_profiles[i + 1],
enabled);
if (ret < 0)
break;
/* go to the next table */
pos += ACPI_SAR_TABLE_SIZE;
}
So, each iteration is always accessing package.elements[3]. I'm not sure
if that is intentional. If it is, then the increment of pos is not
required. Either way, it's not clear what the original intention is.
Colin
Powered by blists - more mailing lists